Skip to article

Transactions and evidence

What evidence should confirm a payment?

Browser returns, success notifications and original-order queries may arrive in different orders. Transact checks them against a fixed order and provider binding so one payment produces one verifiable receipt.

Fix the original order before processing external results

A payment begins with an application identity and merchant order key, fixing the account, payable currency, amount and other declared fields. Equal repeats recover the same record; changed fields under the same key conflict. If the creation reply is lost, the original application key remains a recovery entry without inventing a new transaction identity.

Provider selection then fixes the supplier, merchant and external order. Evidence is always compared against that binding. Payable money uses integer minor units; a display reference price affects presentation only. They are not swapped when a callback arrives. This note explains specified processing rules, not collection or settlement performance.

The original order retains its chosen channel. Notifications and original-order queries supply separate evidence, converging on one conditional commit and one receipt after verification.
Matching success evidence produces one receiptEither a provider notification or an active query can supply success evidence for the original order. Only fully matching evidence can commit a receipt. Timeouts, expired material and unavailable queries still do not establish failure.

A complete match means more than a success status

A success notification first authenticates supplier input, then resolves the unique provider, merchant and external-order binding. It checks the original account, currency and exact amount. Merchant text or an equal amount alone cannot select a cross-application transaction, and a public transaction ID is not the payment-page credential.

When the business application reads a receipt, it builds the comparison context from its own persisted order. Copying the receipt’s amount and account into the expectation would make the check meaningless. Transact’s SDK compares the original fields; the application still owns one fulfillment or ledger effect.

Expected values come from the original declaration
FieldIndependent expectationInsufficient substitute
Application and order keyThe application’s retained declarationText from an incoming callback
AccountAccountId fixed by the original orderThe account currently in the browser
Currency and amountOriginal integer payable amountReference price or rounded approximation
Provider and external orderBinding fixed during provider selectionA success from another provider

A return page establishes navigation

A browser returning after payment does not establish completion. It may return before a notification, or never return after a notification succeeds. QR or link expiry, unpaid or unknown query results and transport timeouts likewise do not create success or definitive failure by themselves.

The page presents the current authoritative inquiry and its unresolved meaning. If the query is unavailable, the result remains unconfirmed rather than becoming unpaid. Once admitted evidence establishes a terminal state, the original order retains it; page refresh does not reopen it.

  • Complete original-order success evidence may commit

    Authenticate the source and compare every original binding before conditional completion.

  • A browser return cannot issue a receipt

    Navigation, timeout and link expiry do not establish payment success.

Notification and query converge on conditional completion

Suppose a notification and original-order query confirm success almost together. Both enter the same conditional completion transaction. The first marks the original PAID, fixes its confirmation time and updates pending work. Repeated completion preserves the original fields and time without incrementing successful amounts. The receipt projects that immutable paid record.

Marking the account as paid is a separate acknowledged duty. Temporary Account unavailability does not revoke an existing receipt. Application fulfillment is also not a side effect of rendering the payment page: the application verifies the original receipt and handles repeated delivery in its own durable state.

Continue uncertain results under the original identity

After a lost create or query reply, return to the original transaction authority, application and merchant key. A replacement authority cannot recover the old order merely because it trusts the same identity issuer. An absent lookup also cannot establish that an earlier or concurrent request never committed.

Collections and payouts require different subsequent actions. A verified paid receipt supports fulfillment. For a payout, the application holds its own reserve and settles or releases it from a matching terminal result. Pending, mismatched, absent or unavailable evidence cannot be treated as definitive failure that releases funds.

Authorize only the next step supported by the result
Observed resultSupported decisionRetain
Verified paid receiptIdempotent fulfillment of the original orderThe application’s fulfillment record
Payout SUCCEEDEDSettle the original reserveOriginal recipient and amount
Payout REJECTED / FAILEDRelease according to the definitive stateThe original rejection or failure meaning
Pending, missing or unavailableKeep the outcome unresolvedOriginal identity and remaining responsibility

Use mismatches and concurrency to verify the evidence

Specified verification uses distinguishable accounts, currencies, amounts and original merchant orders, observing supplier dispatch and conditional completion. One successful example cannot exclude completion of the wrong order.

Independent observations to retain
ScenarioObservationExpected boundary
Same key, different account or amountOriginal record and supplier dispatchesConflict preserves the original
Concurrent successful notification and queryReceipt time, successful total and fulfillmentOne completion without duplicate increments
Return without valid success evidenceThe authoritative current order stateNo PAID state from navigation
Lost creation replyComplete binding recovered by the same keyNo substitute financial identity