A payment app connects Tringify checkout to a merchant's payment-provider account. Your app securely creates or retrieves the provider payment, returns the provider-owned payment experience, verifies the final result with the provider, and reports that result to Tringify.
Before you begin#
You need a Tringify app, an HTTPS service, a development store, and provider test credentials when the provider offers a sandbox. A Standard app is normally the right choice unless the integration also creates a sales channel. Keep all provider credentials in your app; do not place them in Tringify settings or return them from an endpoint.
Permissions and lifecycle delivery#
The payment contract requires read_payment_sessions, write_payment_sessions. Use Add and save required permissions in the provider editor so the scopes become part of the app draft. Configure the app's signed lifecycle webhook before testing: Tringify delivers each installation's scoped token there and uses the same endpoint for later scope rotations. Merchants see new permissions before installing or accepting an update.
Build the integration#
Implement the connection-readiness endpoint so each connected merchant account reports its verified identity, test or live mode, health, and enabled currencies.
Implement the required immediate-charge and amount-aware refund endpoints.
Verify every Tringify signature against the exact raw request body before parsing it, reject stale requests, and make retries idempotent.
Return one documented provider-owned browser handoff for each accepted payment attempt.
Verify provider callbacks and browser returns with the provider, then resolve the payment session through the Store API.
Exercise successful, failed, pending, repeated, expired, full-refund, and partial-refund flows on a development store.
Run provider checks, submit a higher app release for review, and explicitly publish it after approval. Existing merchants accept any required permission update before using the new revision.