Submit your app release when the integration works from account connection through the final payment result. The provider contract is reviewed as part of that immutable release; there is no separate provider submission.
Before you submit#
Complete the connection-check, charge, and refund endpoints declared by the release.
Serve every declared endpoint over public HTTPS and verify signatures against the raw body before parsing.
Demonstrate idempotent charge and refund handling under retries and ambiguous transport failures.
Keep merchant credentials in the app service and customer payment details in the provider-controlled payment experience.
Resolve payment and asynchronous refund outcomes through the Store API with the required scopes.
Verify test-account declarations and reported account mode agree.
Provide accurate setup, support, privacy, and troubleshooting information.
What reviewers exercise#
Reviewers install the submitted release on a development store, connect it with the provider sandbox account you supply, and run the scenarios in Test your payment app: connection checks in each state, a paid checkout, a declined or abandoned payment, a late capture after the session failed or expired, a full and a partial refund, an asynchronous refund resolved through the Store API, and a request with an invalid or stale signature. They also check that merchant credentials never appear in your pages or responses and that payment details stay in the provider-controlled experience.
Evidence to include#
Sandbox credentials, or a sandbox account the reviewer can connect, with the test instruments that produce success, decline, and pending results.
Step-by-step setup instructions for connecting a merchant account in your app's pages.
For each scenario above, the Tringify order number and your app's log lines for it, including
X-Tringify-Request-IDvalues, showing the requests you received and the results you reported.How your app reconciles pending payments and refunds, and how often.