How to Automate Digital Code Delivery

Short Answer

Automating digital code delivery means replacing manual order processing with a pipeline: customer payment triggers an API call to your supplier, the supplier returns the code, and your system delivers it to the customer — all within seconds. The six components are: payment event listener, supplier API order call, code parsing from the response, customer delivery (email/page/message), async completion handling (polling GET /orders/{id} for FoxReload; webhooks if your supplier supports them), and error handling for failed orders. A working automation processes unlimited orders with no manual steps.

Definition: Automated digital code delivery is a fulfillment pipeline that connects customer payment to code delivery without human intervention — using API order creation, webhook events and programmatic code distribution.

Key takeaway: Manual code delivery fails at scale: it introduces delays, human errors and support overhead. Automation removes all three. A single developer can build a system that handles thousands of daily orders with the same effort as ten.

Who This Guide Is For

• Developers building digital goods stores who need to implement the delivery pipeline
• Store operators currently delivering codes manually who want to automate
• Telegram bot developers who want automated top-up and gift card delivery

Why Manual Delivery Fails at Scale

At 20 orders per day, manual works. At 200, it becomes a bottleneck. At 2,000, it breaks.

The Automated Delivery Pipeline

[Customer pays]
      │
      ▼
[Payment gateway webhook/callback fires]
      │
      ▼
[Order handler: validate payment, build order request]
      │
      ▼
[POST /api/orders/ to supplier API]
      │
      ├─[Success]──▶ [Parse code from response]
      │                      │
      │                      ▼
      │              [Deliver code to customer]
      │              (email / order page / bot message)
      │
      └─[Error]───▶ [Log error, alert ops, refund if needed]

Component 1: Payment Event Listener

Your fulfillment pipeline starts when a payment is confirmed — not when it is initiated.

Rules:

• Trigger fulfillment only on a confirmed payment event (not on order creation)
• Handle idempotency: if the same payment event fires twice, do not create two orders
• Validate the payment amount matches the expected product cost

Most payment gateways (Stripe, PayPal, etc.) send a webhook event when payment is confirmed. Subscribe to the correct event type:

• Stripe: payment_intent.succeeded
• PayPal: PAYMENT.CAPTURE.COMPLETED

Never trigger a supplier API call from the client side (browser). Always from your server.

Component 2: Supplier API Order Call

After confirming payment, call the supplier's order creation endpoint:

POST https://public-api.foxreload.com/api/orders/
Content-Type: application/json
X-API-Key: {api_key}

{
  "items": [
    { "itemId": "product_01krgfgww8eth9xvvysd6y7r4j", "quantity": 1 }
  ]
}

Orders are placed by itemId — the product id from the catalog (GET /api/products/). The public API has no offers; you buy a product directly. The response returns an order id; store it against your own order in your database — FoxReload has no client-supplied reference field, so the returned id is your reconciliation key, and the value you poll with GET /api/orders/{order_id}.

What to do on response:

Component 3: Code Parsing

The API response typically contains the code in a structured format. Parse and validate before delivering:

{
  "order_id": "SUP-99887",
  "status": "completed",
  "items": [
    {
      "code": "XXXXX-YYYYY-ZZZZZ",
      "pin": null,
      "instructions": "Redeem at store.steampowered.com"
    }
  ]
}

Validate:

• status is completed (not pending or failed)
• code field is not null or empty
• If the product requires a PIN, pin field is not null

For top-up products, the response may contain a delivery confirmation rather than a code.

Component 4: Customer Delivery

Deliver the code via the channel your customers use:

Always include with the code:

• The code itself (copy-friendly format)
• Product name and denomination
• Activation instructions or link
• Your support contact

Component 5: Async Order Completion Handling

For orders that are not instantly fulfilled (status pending), you need a way to detect when fulfillment completes. How this works depends on your supplier:

• FoxReload: no webhooks — poll GET /api/orders/{order_id} on a schedule until status is terminal.
• Other suppliers: may offer webhooks — your server receives a POST when the order status changes.

If your supplier does support webhooks, the handler requirements are:

Webhook handler requirements:

1. Accept POST request from supplier IP/domain
2. Verify webhook signature (HMAC or similar)
3. Return HTTP 200 within 5 seconds
4. Queue the event for async processing
5. Process: if status = completed → deliver code to customer

Do not:

• Process business logic inside the synchronous webhook handler
• Return non-200 unless you want the supplier to retry
• Assume webhook order matches order creation order

Component 6: Error Handling

Error paths require as much design as the happy path.

Monitoring and Alerting

Set up monitoring on:

Integration Checklist

• Payment confirmation webhook handler implemented and tested
• Idempotency logic: duplicate events do not create duplicate orders
• Supplier API order call implemented with auth header
• All response statuses handled: completed, pending, failed
• Code parsing validates code field is non-empty
• Customer delivery implemented for your primary channel
• Delivery includes code + product name + activation instructions + support contact
• Async completion handling implemented: polling loop for FoxReload (GET /api/orders/{id}); webhook listener if your supplier supports webhooks
• Pending orders monitored — alert if stuck beyond SLA
• Error logging with alerting
• Balance monitoring with low-balance alert
• Load tested at expected peak volume