celerlinksdevelopers
Developer portal
Celerlinks / Integration guides

Sandbox & test scenarios

Build your integration with simulated payments, events, and tickets. Sandbox requests never debit a real wallet or contact a service provider.

Start in the sandbox

  1. Open Developers, select Sandbox, then create a test API key.
  2. Use the sandbox base URL and send your test key as a Bearer token.
  3. Fetch the sandbox catalogue, then make a simulated purchase.
Create a test key
Sandbox base URL
https://api.celerlinks.com/api-service/sandbox
Create a pending test purchase
curl --request POST 'https://api.celerlinks.com/api-service/sandbox/products/buy' \
  --header 'Authorization: Bearer YOUR_TEST_KEY' \
  --header 'Content-Type: application/json' \
  --header 'X-Idempotency-Key: sandbox-order-001' \
  --data '{"product_code":"SB_AIRTIME","recipient_number":"08000000000","amount":1000,"payment_method":"wallet","scenario":"pending"}'

Control the outcome

success

Returns a successful transaction (the default).

failure

Returns a failed transaction.

pending

Returns processing; complete it with the simulate endpoint below.

Send the optional scenario field with a sandbox purchase. Recipient validation supports success and failure. A simulated failure is a business outcome: inspect data.status even when the HTTP response is 200.

Complete a pending transaction
curl --request POST 'https://api.celerlinks.com/api-service/sandbox/transactions/YOUR_ID/simulate' \
  --header 'Authorization: Bearer YOUR_TEST_KEY' \
  --header 'Content-Type: application/json' \
  --data '{"status":"successful"}'

Test products

Use product_type_id 1 for airtime, 2 for data, 3 for electricity, and 4 for TV. The matching biller and category IDs are the same.

SB_AIRTIME

Variable amount in NGN; amount is required.

SB_DATA_1GB

Fixed simulated price: ₦500.

SB_ELECTRICITY

Variable amount in NGN; amount is required.

SB_TV

Fixed simulated price: ₦2,000.

What is simulated

The documented bill catalogue, recipient validation, wallet purchases, transaction lookup, and event/ticket management routes are available under the sandbox base. Events, ticket types, and transactions belong only to the creating account and never appear publicly. Analytics remain zero because no real attendees purchase tickets.

The sandbox wallet is a fixed illustrative balance of ₦100,000, not a ledger. It does not enforce balance limits or PINs. Online checkout, voucher redemption, gift cards, check-in, public event browsing and public ticket checkout are not simulated. Sandbox event validation is simplified; validate your production configuration before publishing.

Retry safely

X-Idempotency-Key is required for sandbox purchases. Repeating the same key and validated request returns the same transaction; changing the request returns 409. Sandbox keys are retained with the record, without the live API’s 24-hour expiry. Use a new key for each scenario.

Connect sandbox webhooks

Add an endpoint with Sandbox selected in the portal. Processing, successful, and failed simulated purchases generate the same event types as live transactions. A pending transaction generates another event when you complete it.

Verify webhook signatures

Switch to live

Create a separate live key and endpoint, change the base URL, and fetch the live catalogue. Test keys are rejected on live integration routes; live keys are rejected in the sandbox. Live purchases use real funds and provider rules.