Skip to main content
Your organization holds a prepaid points pool. Everything your VIPs redeem is ultimately paid for out of that pool. Sandbox activity is always free and never touches it. 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. An organization with no pool yet returns zeros rather than an error.

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 redemption, that redemption is refused.
  • Postpaid (creditLimit > 0): you may overdraw to -creditLimit, and are invoiced for the negative balance at period close. A redemption that would take you past the limit is still refused.
Spendable headroom is therefore balance + creditLimit.

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.