Skip to main content
Your organization holds a points pool. Everything your VIPs redeem is ultimately paid for out of it.

You have two pools, one per key

Your sandbox and live keys draw on completely separate balances: This is the important one: sandbox activity can never spend real money. Redeem as often as you like while you build, run the sandbox pool into its overdraft, watch the balance move - none of it touches your live balance and none of it reaches an invoice. Ask us to raise your sandbox headroom if you need more room to test. GET /v1/balance always reports the pool belonging to the key you called it with, so the same request returns different figures for a sandbox key and a live key. That is the intended behaviour, not a bug.
A live pool that has not been funded yet returns creditLimit: 0 and refuses every redemption with 402 INSUFFICIENT_ORG_POINTS. That is deliberate: it fails closed rather than fulfilling an experience nobody has paid for. Build against your sandbox key until your live pool is funded.
What differs between organizations is which layer a redemption debits - your settlement mode.

The two settlement modes

Member wallet

The default. Each VIP has their own wallet. You fund a VIP by calling POST /v1/wallet/credit, which draws your pool down. When that VIP redeems, the points come out of their wallet.Use this when you want per-VIP balances that your users can see and you are happy for Expys to hold them.

Org pool

No per-VIP balances at all. You never call /v1/wallet/credit. When a VIP redeems, the points are debited straight from your org pool, and the booking is attributed to that VIP for reporting.Use this when you already run your own loyalty balance and do not want to mirror or reconcile it with ours.
Your settlement mode is configured by Expys, not self-serve. Ask your Expys contact to change it. Read your current mode from GET /v1/balance.

What org-pool mode changes for you

  • You never credit wallets. POST /v1/wallet/credit is not part of your integration.
  • GET /v1/wallet reports zero for your VIPs, because there is no member wallet in play. That is expected, not a bug - the cleanest setup is simply not to grant WALLET_READ on your key.
  • No per-redemption webhook fires. There is no wallet movement to report, so neither wallet.credited nor wallet.debited is emitted. Poll GET /v1/balance, or subscribe to org.points.low, to track the pool.
  • Analytics still work. GET /v1/analytics/offers and /v1/analytics/timeseries report pool-settled spend exactly as they report wallet-settled spend.

Reading your balance

GET /v1/balance is server-side only: it needs an Org-API-Key with the BILLING_READ scope. It reports the pool for the environment of the key you used
  • a sandbox key reads the sandbox pool, a live key the live one. An organization with no pool in that environment returns zeros rather than an error.
Every money field also comes with ...USD and ...Display siblings, denominated in dollars and in your own currency - see Points and wallet.

Prepaid and postpaid

Both are the same mechanism, controlled by creditLimit:
  • Prepaid (creditLimit: 0, the default): the pool can never go negative. The moment it cannot cover a draw, that draw is refused.
  • Postpaid (creditLimit > 0): you may overdraw to -creditLimit, and are invoiced for the negative balance at period close. A draw that would take you past the limit is still refused.
The limit is per pool, so your sandbox can carry generous headroom for testing while your live pool stays on whatever commercial terms you have agreed. Sandbox overdraft is never invoiced. Spendable headroom is therefore balance + creditLimit. This applies to both ways your pool is drawn down - a redemption settled from the pool in org-pool mode, and a POST /v1/wallet/credit that mints points into a VIP’s wallet in member-wallet mode. Whichever mode you are on, the limit is the same ceiling and the same 402.

Funding the pool

Enterprise grant

For a signed contract paid by invoice or wire, our team grants your pool an allotment directly - no card needed. Ask your Expys contact.

Self-serve purchase

Buy points any time from the portal Billing page. You are taken to Stripe to pay; your balance updates as soon as payment is confirmed.
Your balance and full grant / purchase / spend history are on the Billing page of the developer portal.

Webhooks

Subscribe to keep your systems in step with the pool: See Webhooks for delivery, signing, and retries.

Handling an empty pool

This 402 surfaces on POST /v1/wallet/credit in member-wallet mode, and on POST /v1/redemptions in org-pool mode. Either way it is all-or-nothing: no points move, and in org-pool mode no booking is created. Top the pool up (grant or purchase) and retry.
In member-wallet mode, an organization with no pool at all is ungated - distributions are free until your first top-up sets the pool up. Org-pool mode is never ungated: without a funded pool, every redemption is refused.