Testing

Build confidence in every payment.

Use Test mode, ak_test keys, sample invoices, and signed webhook events to verify your complete customer journey.

Create a test invoice

Use a unique invoice reference and invoice lines for every test.

Try each payment path

Check successful, in-progress, failed, retried, and expired payments through hosted checkout.

Replay a webhook

Send the same event ID more than once and confirm your system updates the order once.

Review your records

Use invoice_ref to connect the checkout, invoice, webhook, and settlement records.

Test checklist

Test the moments that matter to your customers.

Successful checkout

Receive checkout.session.completed. Confirm the amount, currency, and invoice reference before you fulfil.

Payment still being confirmed

Keep the order open while finalized is false. Give your customer a clear status.

Failure and expiry

Confirm failed or expired sessions never release an order.

Signature rejection

Change one byte in the raw body or timestamp. Your handler must reject the delivery before it updates the order.

Safe retry

Retry session and invoice-line writes with the same Idempotency-Key and body. A changed request needs a new key.

Test data

Build with predictable, repeatable examples.

Use an ak_test_ key with the normal API. Test payments are synthetic: they never contact a bank, wallet, teller, or live settlement system. Start a checkout, select Mobile Money, Bank transfer, or Cash, then use the test outcome endpoint to exercise your webhook receiver. Use pending when you need to keep the payment open.

API keyak_test_...

Invoice referenceINV-2026-001

Outcome endpointPOST /api/v1/test/payment-attempts/{reference}/simulate

Outcomespending, paid, failed, expired, cancelled, reversed, manual_review, amount_mismatch

Simulate a paid test payment

curl https://api.quiddpayments.com/api/v1/test/payment-attempts/s_test_example/simulate \
  -H "Authorization: Bearer ak_test_example" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: test-outcome-s-test-example-paid" \
  -d '{"outcome":"paid"}'

API base URLhttps://api.quiddpayments.com

Developer tools

Give your team the right starting point.

ReferenceExplore the API

Review endpoint fields, examples, status codes, and schemas.

OpenAPIDownload the schema

Generate clients and review the integration contract.

MarkdownRead the guide in Markdown

Use a portable guide in your engineering workflow.

LLMsUse llms.txt

Give developer tools a compact integration map.

CollectionImport test requests

Run examples for the core payment journey.

Versioning

Build on a dependable API.

Quid Payments adds optional response fields without disrupting your integration. We provide a migration note before required fields, event names, signature rules, or error-code meanings change.

Current API version2026-06

Checkout sessions, invoice lines, payment methods, cash deposits, webhooks, and errors.

Changes that need your actionMigration note first

You receive a clear upgrade path before required fields or final checkout rules change.

Before you launch

Make every payment journey ready for customers.

Successful, failed, and expired checkouts update orders correctly.
Your webhook receiver verifies raw-body signatures and processes each event ID once.
Your server uses idempotency keys for checkout and invoice-line writes.
Your team can trace an invoice_ref through checkout, webhook, and settlement records.
Your checkout shows the payment methods available to your customers.