Skip to content

Sandbox & test cards

The dev environment is the sandbox. All API calls, orders, and payments in dev are isolated from production. No real money moves.

ServiceURL
APIhttps://pos-api.dev.apps.myfinterra.com
Admin portalhttps://admin.dev.apps.myfinterra.com
POShttps://pos.dev.apps.myfinterra.com
Docshttps://docs.dev.apps.myfinterra.com
Token endpointhttps://tilt-m2m-dev.auth.us-east-1.amazoncognito.com/oauth2/token

These numbers work in the dev environment only. Use any future expiry date (e.g. 12/26), any 3-digit CVV, and any 5-digit ZIP.

Card numberNetworkResult
4111 1111 1111 1111VisaApproved
4000 0000 0000 0002VisaDeclined — do not honor
5500 0000 0000 0004MastercardApproved
3714 4963 5398 431AmexApproved
6011 1111 1111 1117DiscoverApproved
ScenarioHow to trigger
Approved paymentAny approved card number above
Declined paymentCard 4000 0000 0000 0002
Partial approvalNot currently supported in sandbox
RefundCreate an approved payment, then call the refund endpoint
VoidCreate an approved payment, then call the void endpoint before midnight

Use webhook.site to get a temporary HTTPS URL for webhook delivery testing. Register it as an endpoint in the admin portal (Integrations tab) and watch events arrive in real time.

Sandbox M2M clients are managed in the dev admin portal. They are separate from production clients — a dev client_id/secret will not work against the production API.

Rate limits are enforced in the sandbox at the low tier by default, regardless of the client’s configured tier. If you need higher limits for load testing, contact your account manager.

  • Settlement simulation: payments move from approved to settled on a simulated nightly batch (runs at midnight UTC). In production, settlement timing is processor-dependent.
  • Processor webhooks (Aeropay): async ACH settlement events may be delayed up to 1 minute in sandbox vs. near-real-time in production.