Skip to main content
Test mode uses a pk_test_ key or an OAuth application registered in TEST mode. It shares the production API shape, but write behaviour is deliberately narrow.

​
What a test key can do

  • Read cards, locations, customers, enrolments, transactions, and webhook configuration.
  • Create test ledger transactions against an existing enrolment.
  • Call /marketplace/accrue for an existing customer and existing enrolment.
  • Simulate wallet pushes without delivering a notification.
  • Receive signed transaction webhooks marked with testMode: true.
  • List and clean up test transactions.

​
What it cannot do

  • Create, update, or anonymise a live customer.
  • Create or change a live enrolment.
  • Create, edit, or delete webhook configuration.
  • Use /marketplace/enroll.
  • Create a customer or enrolment as a side effect of /marketplace/accrue.
  • Deliver a real wallet push.
These restrictions apply on the server even if an older key row contains an unsafe scope. The dashboard also removes unsupported scopes when a test key is created or edited.

​
Testing a POS transaction

  1. Use GET /customers or a scanned card_serial to resolve a customer.
  2. Use GET /enrollments to find the matching card enrolment.
  3. Post the transaction with a stable external_transaction_id.
  4. Confirm the response includes test_mode: true.
  5. Confirm your webhook receiver branches on testMode.
Prefix test transaction references with test:. The same permanent reference cannot be reused later for a live transaction. To remove all test ledger rows after certification:
Test reads return the business’s current records so an integration can prove its matching logic. Treat test keys as sensitive because those records can contain personal data.

Related topics

Bulk-delete every test-mode transaction for the orgSend a wallet pushQuickstartGo-live checklistSend push notifications