Offers: order bump, upsell and downsell

Overview

An offer is a reusable price you register once and reuse across many sales. There are three kinds:

• Order bump: shown at checkout as a quick add-on and, when accepted, enters as an extra line item on the charge being created.
• Upsell: a one-click post-purchase offer, usually a higher-value item, that creates a new charge for the contact.
• Downsell: also one-click post-purchase, used as a cheaper alternative when the customer declines the upsell — it likewise creates a new charge.

In every case the offer holds a name, amount, currency and method; you only attach it to a sale or a contact at the right moment.

Prerequisites

• A connected and valid gateway (see Connect a gateway).
• Optional: a Catalog product linked to the offer (catalog_product_id), to reuse the product record.
• Set the connection (gateway) and the method (billing_type) on the offer, used when it becomes a charge — especially for upsell and downsell.
• To accept an offer (upsell/downsell), the contact needs minimal data (name and, ideally, email/phone) for the payer at the gateway.

How it works

• Order bump at checkout: the offer is converted into a charge line item (name, amount and currency are snapshotted at that moment). It adds to the total by appending a new line — it never changes the amount of an existing charge. The line only keeps a reference to the offer in its metadata.
• Upsell / downsell after purchase: when you accept the offer for a contact, the platform creates a new charge reusing the connection, the amount and the payer data already known — with nothing to retype. That charge follows the normal flow (gateway → webhook → payment card in the conversation), exactly like any other charge.
• The offer is never modified when accepted: it is a template; each acceptance creates a new, independent charge.
• Post-purchase acceptance only works for an active, non-archived offer. An order bump belongs to checkout and is rejected by this action. Repeating the same network attempt recovers the same charge.

Step by step

1. In the Payments area, open Offers and create a new offer.
2. Enter a name, pick the kind (order bump, upsell or downsell), the amount and the currency.
3. Set the method and the connection (gateway) used when generating the charge.
4. (Optional) Link a catalog product and write a description.
5. Save. The offer is available while it is active.
6. To apply an order bump, use the offer at checkout: once the customer accepts it, it becomes an extra line on the charge.
7. To accept an upsell/downsell, an authorized integration calls the acceptance API for the contact, with explicit company and conversation context when applicable. The operation creates a new charge; creating the catalog offer does not perform that acceptance.
8. To retire an offer, archive it — it disappears from the available offers, but the price is preserved (we never delete a price an active funnel may reference).

Settings & options

Catalog, acceptance and payer are separate decisions

Creating or saving an offer only registers a catalog option; it does not create a charge or start a subscription. The Offers screen manages that catalog. This version has no post-purchase acceptance button on that screen.

An authorized integration can accept an upsell/downsell through the API. Acceptance requires the responsible contact and may explicitly supply organization_id to bill a company linked to that contact; conversation_id preserves the conversation context when supplied. The company fiscal record must satisfy the chosen gateway and method. Without an explicit company choice, do not infer the payer from a product or deal. The attempt must keep its idempotency key; acceptance is a financial operation, not a catalog lookup.

An order bump is only an additional line in the checkout being composed. Saving the offer or adding that line does not issue a charge by itself. The post-purchase acceptance endpoint rejects order bumps; do not use it to start an implicit charge. Issuing the charge and any delivery in the conversation remain separate actions in the charging workflow.

Offer fields:

Use cases

• Raise the ticket with an order bump at checkout ("add the extended warranty for $19.90").
• Offer an upsell right after purchase ("get the Pro version in one click").
• Recover the sale with a downsell when the customer declines the pricier upsell.
• Reuse the same offer across many conversations and checkouts, without re-creating the price.

Tips, limits & best practices

• The order bump does not change an already-created charge — it only adds a line to the total at checkout time.
• Accepting an upsell/downsell always creates a new and independent charge; the original offer stays intact.
• Offers are archived, not deleted — so no funnel or history that depends on that price breaks.
• Set the connection and method on the upsell/downsell offer: without them, the acceptance cannot generate the charge correctly.
• Amounts are in major units ($49.90 = 49.90); the checkout total is the sum of the lines — never divide by 100.

Troubleshooting

• The offer does not appear: check that it is active and not archived (inactive or archived offers are not presented).
• Acceptance failed: confirm the contact has the minimal data and that the offer's connection (gateway) is valid — acceptance creates a real charge and needs that data.
• The order bump amount looks wrong: remember it adds a line to the total; it does not replace or reduce the other lines.
• I can't delete an offer: offers are archived (reversible), not removed — use archive.

See also

• Create a charge and send it in the conversation
• Connect a gateway: Asaas and Mercado Pago
• Native catalog of products and services