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
When to use B2B
Use /b2b when you are the buyer: you fund a USD balance with deposits, 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.
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.
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.
- 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. 
