Digiseller API: Automating Payment and Delivery

Digiseller is a payment and auto-delivery engine first and a storefront second. The value for a reseller appears only when a product card is served not by a person and not by an uploaded text file, but by your own service that calls a wholesale supplier the moment payment lands and returns a working code. This article walks through how that integration is built, where it breaks and how to fix it.

If you have not worked with the platform yet, start with the basics in selling on Digiseller.

What the Digiseller API covers

The API splits into a handful of meaningful blocks. Verify method names and parameters against the current Digiseller documentation — it changes; what follows is the logic, not the signature list.

There is also a buyer-messaging block. It does not automate a sale, but it matters if you build support on top of the platform.

The token is not a constant

Tokens expire, and the request is signed with a hash over your secret and a timestamp. Practical consequence: do not request a fresh token on every call and do not cache one forever. The right pattern is to store the token with its expiry, refresh it a minute or two before it lapses, and perform exactly one forced re-auth if you get an expired-authorisation response.

The payment to delivery flow, step by step

Here is the chain as your backend sees it.

1. The buyer pays on a Digiseller storefront or on Plati.Market. The money is held on the platform side and is not yet finally yours.
2. The platform reports the sale. Either you receive a notification at your URL, or your service polls the API by order. Notifications are faster, polling is more reliable — in practice you need both.
3. You verify authenticity. Never trust the notification body on its own: call the API back by order number and confirm that the sale exists, the amount matches and the product is the one you expect.
4. You look the order up in your own database. If a record exists and a code was already issued, return that stored code. If not, create a record in an in-progress state.
5. You call the wholesale source. Your service places an order with the supplier for the mapped SKU and receives a code.
6. You deliver the content to the buyer and mark the order delivered on the platform.
7. You write the result back — code, purchase cost, supplier order ID, timestamp.

Steps 4 and 7 are the ones people skip, and they are exactly what turns a demo into a system. The state logic is covered in more depth in how an API order flow works.

An upstream supplier behind the product card

The idea is simple: the card on the platform is the shop window, the warehouse sits with the wholesaler. At the moment of sale your middleware translates the platform SKU into the supplier SKU, places the order and returns the code.

What you need for that:

• A mapping table. One platform product to one supplier product, plus region and denomination. Without an explicit activation region you will generate a stream of refunds.
• Availability checks before the sale. Poll supplier stock and pull items from sale when they are gone — far cheaper than cancelling a paid order.
• A fallback source. A second supplier on your top SKUs removes most of the stockout risk.
• Cost-price control. Wholesale prices move; if you do not push updates to the storefront you will sell below cost for a while without noticing.

Idempotency lives in your database, not in a header

The most expensive failure mode is buying the same code twice for one sale. The causes are mundane: a repeated platform notification, a timeout on your call to the supplier, a worker restart.

Do not assume a supplier-side idempotency header will save you. The FoxReload API, for instance, has no Idempotency-Key header — a repeated POST creates a second order. A different pattern works:

• write your intent to your own database before calling the supplier — platform sale ID, SKU, timestamp, status pending;
• on any ambiguous error (timeout, dropped connection, 5xx) check status first — pull the supplier's recent orders and look for yours by SKU and time;
• create a new order only once you have confirmed the previous one does not exist;
• a unique index on the platform sale ID in your table is the last line of defence.

The full pattern is covered in idempotency keys and safe retries.

Retries and queueing

Classify errors and react differently to each class.

Make backoff grow and add a little jitter, otherwise every worker you own will hit the supplier in one wave the second it recovers. Cap the attempt count: an order that has not settled within a reasonable window belongs in a manual queue, not in an infinite loop.

Reconciliation separates profit from the illusion of profit

Automation without reconciliation produces a pretty and wrong picture. The daily minimum:

• Platform sales against your orders. Every sale must map to exactly one supplier order.
• Supplier orders against delivered codes. A code you bought but never delivered is pure loss and a future dispute.
• Money. Platform revenue minus platform fees minus cost of goods minus withdrawal fees. That, and only that, is margin.
• Stuck orders. Anything sitting in pending longer than N minutes goes into a report.

Discrepancies always exist. What matters is that you find them automatically rather than through a buyer complaint.

Where to source inventory for this setup

The whole design is only as good as the source behind the card. The FoxReload wholesale catalog fills that role: 900+ SKUs across game keys, gift cards, top-ups and subscriptions, a single REST API instead of a dozen fragmented suppliers, and automatic delivery. That lets you keep one integration layer behind your Digiseller storefront instead of rewriting code every time the supplier for a given item changes.

Related reading: automating digital code delivery, order webhooks and connecting SBP to Digiseller.