A payment declaration is the versioned contract included in an app release. It identifies the HTTPS endpoints Tringify may call and whether the integration supports provider test accounts. Account identity, readiness, mode, and enabled currencies are reported separately by each installed connection; they are not declaration settings.
Payment protocol#
New declarations use payment protocol 1 automatically. The protocol defines the signed charge, refund, and connection-check requests your app receives and the responses it returns. Tringify selects the supported protocol; developers do not choose or change it independently.
Support test accounts#
Enable this only when the integration can connect provider sandbox credentials and keep them isolated from live credentials. The connection check still reports the actual account mode as test or live; this declaration setting only states that test connections are supported by the reviewed release.
Required HTTPS endpoints#
Provide a public HTTPS connection-check endpoint and one endpoint for each required operation below. Tringify signs every request. Drafts may be incomplete while you work, but release submission rejects a missing or invalid endpoint.
Operation |
Value |
Purpose |
|---|---|---|
Charge |
|
Create or retrieve a shopper payment for the exact amount and currency Tringify sends, then return one approved provider-owned browser handoff. |
Refund |
|
Return the exact amount Tringify sends from a successfully captured charge. The amount may be the full remaining balance or a partial refund. |
Customer payment choices are not capabilities#
Do not declare card, bank-transfer, wallet, or device-specific choices. Return one approved browser handoff from the charge endpoint and present the choices available to that customer inside the provider-owned experience. Availability may differ by connected account, currency, customer, and device.
Frozen with the release#
Submission freezes the protocol, test-account capability, connection-check endpoint, charge endpoint, and refund endpoint into the release revision. Editing the next draft does not alter approved releases or installed stores. Publish the approved release explicitly; existing merchants remain on their installed revision until they accept an applicable update. When an installed declaration changes, Tringify atomically repoints its connections to that revision, disables those connections, and clears the old capability snapshot. Re-run the connection check and enable the connection before the provider can appear in checkout again.