Skip to content

First completed sandbox payment

Use the existing Setup guide in Sandbox. Account prerequisites and app checks are separate. Completion requires provider evidence and a committed payment.completed delivery acknowledgement; HTTP 200 initiation and a browser return redirect do not prove payment.

  1. Verify email, business profile and operating plan. Use Prepare automatically for wallet and ledger prerequisites.
  2. Create or select the sandbox app. Select a provider in Payment Gateways, then configure its credentials on this app and its allowed currency. Account provider selection alone is insufficient. Use an explicit gateway for the first test; routing rules are optional and can be configured later through Routing Rules.
  3. Configure that app’s public HTTPS webhook and signing secret. Run the diagnostic receiver described below behind your approved HTTPS ingress, then Send test webhook in Setup guide. Use raw request bytes for signature verification; private destinations are rejected.
  4. Click Start measured trial. Set the count of assisted interventions when human help was needed. Retrying keeps the original server start. App/webhook configuration or readiness-version changes require a new trial.
  5. Authenticate the app with its test public/secret keys using the token endpoint. Use the bearer token on your backend. App keys, provider keys and webhook signing secrets are different credentials.
  6. Run client.mjs from the source example. It writes a private state file before initiation. Keep that same file after a timeout. HTTP 202 remains reserved: reopen the original operation and reuse its key, never create a fresh payment.
  7. For hosted checkout, open authorizationUrl and complete the provider’s test flow. Use provider-specific test instructions; the default sample is Stripe, USD and 25 major units. Do not use production credentials or money.
  8. Run client.mjs --query with the same state file. Initiation returns paymentReference; query sends reference and the original gateway. Wait for status success and the receiver’s payment.completed event. Refresh Setup guide to confirm the committed acknowledgement and observed elapsed time.

Runnable source example

The backend checkout contains examples/first-payment/client.mjs, receiver.mjs and instructions. Requires Node 22+. Use the example to confirm your app’s payment and webhook setup.

Open the source example and README
Commands after setting backend environment variables
# On the receiver server: set TINKER_WEBHOOK_SECRET securely.
node receiver.mjs

# On your application backend: set TINKER_API_URL (including /v1),
# TINKER_APP_ID and TINKER_TOKEN securely. Never put secrets in browser code.
# Set TINKER_TEST_GATEWAY, TINKER_TEST_CURRENCY and TINKER_TEST_AMOUNT
# to the provider and currency shown by the wizard before the first run.
node client.mjs
# Finish provider sandbox checkout, then query the same state file.
node client.mjs --query
Illustrative request: POST /v1/merchant/payment/initiate
Authorization: Bearer <app-token>
Content-Type: application/json
Idempotency-Key: <saved-unique-key>

{
  "amount": 25,
  "currency": "USD",
  "gateway": "stripe",
  "merchantReference": "ORDER-12345",
  "returnUrl": "https://your-app.example/payment/return",
  "customerEmail": "[email protected]"
}

Troubleshooting and evidence

  • No provider configuration: check this app’s credentials, enabled gateway and currency. Local configuration checks do not prove credentials are accepted remotely; the successful test collection provides that evidence for this run.
  • Webhook not acknowledged: check public HTTPS reachability, the selected app’s signing secret, raw-body verification and a 2xx after durable processing. Readiness never uses another app’s log.
  • Payment accepted but still pending: finish provider checkout, query the original reference and inspect Payment Operations. An accepted initiation does not finish the wizard.
  • Completion observed but delivery pending: inspect the payment’s operational trace for retained work. Do not delete events or re-initiate to clear the queue.
  • App name/configuration or webhook secret/URL changed: checks and the current trial are invalidated conservatively. Refresh and rerun diagnostics. Changing provider credentials is not a continuous live health check.

For your live app, store event IDs and order updates together before returning a successful webhook response. Use the example receiver to test your integration, then connect your own order-fulfilment logic.

Idempotency · Delivery semantics · Recovery runbook · SDK setup instructions