> ## Documentation Index
> Fetch the complete documentation index at: https://docs.wizzgift.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Choosing a surface

> B2B or Retailer — who pays, and which mode fits your business.

One account, one API key, two surfaces. Pick the one that matches who pays and who receives the codes — or use both side by side.

## Comparison

|                | B2B (`/b2b`)                                       | Retailer (`/retailer/v1`)                                                         |
| -------------- | -------------------------------------------------- | --------------------------------------------------------------------------------- |
| Who pays       | You, from prepaid balance                          | Your end-customer (crypto invoice or hosted page), or you via prepaid balance     |
| Payment timing | Instant — order create pays and starts fulfillment | After the customer pays the invoice                                               |
| Codes go to    | You (fetch via API)                                | You (fetch via API and relay to your customer)                                    |
| Your pricing   | Catalog price minus your negotiated discount       | Catalog price plus your `markupPercent` — markup is credited back to your balance |
| Notifications  | Optional plain callback (unsigned, no retries)     | Signed webhooks with retries                                                      |
| Best for       | Bulk purchasing, internal distribution             | Storefronts, reseller sites, checkout embedding                                   |

## When to use B2B

Use `/b2b` when you are the buyer: you fund a USD balance with [deposits](/quickstart/b2b), then place orders that are paid instantly from that balance. There is no per-order payment flow to manage — the only asynchronous part is fulfillment itself.

## When to use Retailer

Use `/retailer/v1` when someone else is the buyer: you create a checkout for your end-customer, they pay it (or you redirect them to our hosted payment page), and you deliver the codes once fulfillment completes. You control your margin per checkout with `markupPercent`, and completed items credit that markup to your balance.

<Tip>
  The retailer surface also supports a prepaid mode: pay a checkout with the *balance* payment method and skip the customer invoice entirely. This is useful when you collect payment on your own side and just need fulfillment.
</Tip>

## How the surfaces stay separated

Orders created on one surface never appear in the other's list endpoints — `GET /b2b/orders` only returns B2B orders, and `GET /retailer/v1/checkouts` only returns retailer checkouts, even though both belong to the same account.

`externalRef` (your own order id) is unique per account **across both surfaces**:

* Reusing a ref on the *same* surface returns the existing order (`200`) — that is the [idempotency mechanism](/guides/idempotency).
* Reusing a ref on the *other* surface returns `409 CONFLICT` — that is a bug in your integration, not a replay.

## Shared account state

Balance, tier, limits, and rebate progress are account-wide. `GET /b2b/account` and `GET /retailer/v1/account` return the same core data; the retailer variant adds open-checkout usage and your markup ceiling.