Testing in Sandbox
The Luqra Now sandbox environment lets you test contact creation, payment submission, and error handling without moving real funds.
Sandbox vs production
| Sandbox | Production | |
|---|---|---|
| Key prefix | luqra-now.org.test |
luqra-now.org.live |
| Fund movement | None | Real |
| Payment rails | Simulated | Live |
| Bank account validation | Format-check | Format-check |
Getting started
Use your sandbox API key for all test requests:
curl "https://staging.api.now.luqra.com/v1/contacts/?originatorId=ORIGINATOR_ID" \
-H "Authorization: Bearer luqra-now.org.test.YOUR_API_KEY"
Sandbox and production share the same API endpoints. The environment is determined entirely by your API key prefix.
Test bank accounts
Bank account validation checks the format -- routing numbers must be 9 digits with a valid ABA checksum, and account numbers must be 5-17 alphanumeric characters. This applies to both sandbox and production.
You can use any well-formed routing and account number for testing:
| Routing number | Description |
|---|---|
021000021 |
JPMorgan Chase (valid checksum) |
011401533 |
Bank of America (valid checksum) |
091000019 |
Federal Reserve Bank (valid checksum) |
Payment processing in sandbox
Sandbox payments progress through the full lifecycle without moving real funds. An intent moves from QUEUED to PROCESSING and on to COMPLETED once the simulated rail acknowledges the payment. The timing of the simulated sandbox environment matches the timing in production.
RETURNED and FAILED_IN_FLIGHT are not produced automatically in sandbox. To exercise handling for these statuses, see the Payment Lifecycle reference and structure your code to react to status fields directly rather than relying on observing every transition during sandbox testing.
Testing error scenarios
To test how your integration handles failures, you can:
- Invalid contact -- Send a payment to a
contactIdthat doesn't belong to the originator. Returns a404error. - Missing fields -- Omit required fields to trigger
400validation errors with detailed field-level messages. - Idempotency replay -- Send two
POST /v1/paymentsrequests with the sameIdempotency-Keyand the same body. The second returns the original payment id. Send a third request with the same key but a different body -- it returns409IDEMPOTENCY_KEY_REUSED_WITH_DIFFERENT_BODY. - Missing
Idempotency-Key-- Omit the header onPOST /v1/paymentsto trigger400IDEMPOTENCY_KEY_REQUIRED. - Expired keys -- Use a revoked API key to verify your error handling for
401responses.
Best practices
- Use sandbox for all development and staging environments. Never use production keys in non-production environments.
- Validate error handling. Intentionally trigger errors to make sure your integration handles them gracefully.
- Test idempotency. Send a payment, then retry with the same
Idempotency-Keyand verify that no duplicate is created.