Test your payment app

Exercise the paths that protect merchants and customers before requesting review.

Validate the complete integration on a development store with a provider sandbox account before submitting the release.

Test orders and stored value#

Development and transfer stores take test payments only. Each one has the Tringify test gateway, Test Payment Provider, installed and enabled, and your app's connection can be enabled there in test mode only. Test orders cannot spend gift-card or store-credit balances; remove those payment selections and use a test provider. The Store API returns TEST_ORDER_STORED_VALUE_UNAVAILABLE if a test-order request includes stored-value redemption. Test payments can be refunded through the original test provider. A simulated payment cannot create spendable store credit through a refund. Older orders that actually spent store credit may return only the original unrefunded credit.

Essential scenarios#

Return requires_action, error, and ready from connection checks and verify that only a ready account is assignable.
Verify test and live modes cannot be confused and that checkout offers only currencies in the accepted connection snapshot.
Resolve paid only with the exact session amount, currency, and provider transaction ID; verify mismatches are rejected.
Keep a retryable provider order pending after one attempt fails, then reconcile its complete provider state.
Retry an identical charge request after an ambiguous timeout and verify that one provider payment exists.
Repeat the same terminal resolution and verify idempotency; verify paid cannot be downgraded.
Reject invalid and stale signatures before creating provider state.
Verify an authoritative late capture promotes failed, expired, and cancelled sessions exactly once.
Create distinct full and partial refunds. Reuse each refund's own refund_id only when retrying that same refund.
Return an asynchronous refund as pending, then resolve it through the Store API. Verify repeated and contradictory outcomes against the refund transition rules.
Answer a charge request after the 30 seconds limit and verify the session fails, a replacement attempt arrives with a new session_id, and a later capture of the first provider payment still resolves that first session as paid.
Leave a refund request unanswered and verify the repeated request carries the same refund_id and creates no second provider refund.
Deliver an old app.uninstalled after a reinstall and an old app.token_rotated after a newer one, and verify neither changes the current installation.