Identity and payments
Transact
Fixed-amount collection and original-order verification
Transact gives business backends fixed-amount collection, direct provider payouts and original-order queries. Each transaction first records its account, amount, currency and declaration, then advances from matching provider evidence. Either a provider notification or an active query can supply valid success evidence. Verification and commit retain one receipt for the original order. Applications remain responsible for balances, reserved funds, risk decisions and fulfillment.
Confirm an original payment after a missing notification The payer completes the provider flow, but the business has not yet received a result. The service queries the same order through its bound channel and stores the receipt once complete success evidence is available. The business then verifies that receipt and completes its own delivery.
Persist the declaration before provider work
A business backend uses scoped Account authorization to submit its application-local order key, account, title and amount. First admission freezes the declaration; an equal repeat retrieves the same order, while changed original fields conflict. Amounts use integer minor units with an explicit currency and no exchange conversion.
The payment page uses an independent random link credential. An order identifier alone cannot authorize provider selection. Available choices depend on configured products, currency, amount, title and return-URL admission. Links, QR codes and browser returns help continue an original order; none proves payment.
Connect the original business order to your own fulfillment record
The business first retains its order declaration: application-local order key, account, title, currency and an integer amount in minor units. It calls the transaction service using that identity. When a receipt returns, the SDK compares it with the business’s retained original fields, not with payment-page text or a browser-return status.
Transact owns the original provider transaction and confirmed receipt. Delivery, entitlement grants and business balances belong to the caller. The caller associates that receipt with its original order and prevents repeated fulfillment in its own ledger. A payout also needs prior business authorization and reserved funds; an unknown result does not establish that funds can safely be released.
Retain and submit the original declaration
Fix the application-local identity and exact amount. The same declaration retrieves the original order; changed fields are a conflict.
Let the payer continue that order
Use the separate access credential to obtain eligible channels and payment material. Once selected, the channel remains bound to the original order.
Verify the receipt before fulfillment
Compare the original account, currency, amount and order relationship, then record the business’s own delivery result.
Define the product selected for each provider
Collection uses WeChat and Douyin Native QR products, Alipay desktop or mobile web payment, and the Stripe Checkout hosted payment page. The selected provider remains bound to its original order; a processing payment cannot switch into another provider transaction. QR supports scanning and does not imply a separate same-device mobile payment route.
For a payout, the application first authorizes the transfer and reserves its own funds. Transact reads the Alipay or Douyin user identifier, OpenID, already bound in Account, checks its issuing application against the merchant product, then freezes the recipient and transfer number. Recovery retains that recipient through later account configuration changes.
| Provider | Collection entry | Direct payout |
|---|---|---|
| Native QR; CNY | Not selected | |
| Douyin | Native QR; CNY | CNY to the Account-bound OpenID |
| Alipay | PAGE / WAP link; CNY | CNY to the Account-bound OpenID |
| Stripe | Hosted Checkout; configured CNY / USD ranges | Not selected |
Let notifications and queries establish one result
A success notification is authenticated under the provider’s signature or encrypted-message contract, then checked against the merchant, original order, account, currency and exact amount. Complete success evidence enters one conditional completion transaction. Original-order queries use the same entry, preserving one receipt, confirmation time and summary increment under duplicate or concurrent evidence.
Payment confirmation also records a pending Account paid-state duty, delivered by independent work. An identity-service outage does not undo the receipt. Timeout, expired payment material, a missing query result or an unpaid observation cannot by itself establish failure. Failure requires definitive evidence that the original is nonpayable.
| Evidence obtained | Permitted business handling | Not established |
|---|---|---|
| Receipt matching the original declaration | Idempotent fulfillment | An account balance or merchant net settlement |
| Successful payout / definitive failure or rejection | Settle / release the original reserve | Permission to choose another recipient |
| Pending, absent or unavailable result | Retain responsibility and investigate | Returned funds or the end of financial responsibility |
Recover the original and preserve uncertainty
Restart discovers committed originals and unfinished work, using each provider’s supported original-number recovery. A Stripe Checkout Session can be created only by the live task that definitively committed the winning selection. An uncertain send, lost waiter or process exit does not let a restarted worker create another Session merely because an idempotency key exists.
A missing Stripe Session identifier or exhausted provider query window leaves the original state intact and calls for merchant investigation. An authorized operator can submit a recovered Session identifier; the service verifies its merchant and original binding before restoring queries or confirming collection. Reconciliation creates no Session and accepts no caller-supplied payment verdict.
Investigate uncertainty within the original order and channel
Recovery starts with the original application order key and any retained provider identifier. A valid notification or an original-order query can independently establish success; both are not required. Either source must pass the same original-field comparison before the conditional commit. After success has committed, later evidence returns the original receipt without another posting.
A missing record, expired wait or unusable payment page establishes only an incomplete observation. If a Stripe Session identifier is missing or the original channel can no longer be queried, retain the order for merchant investigation. Do not replace uncertainty with a new order, channel or recipient. A recovered candidate identifier must still be verified against the original order.
Admission condition: either valid success source matches the order
An authenticated notification or an original-order query can enter the same conditional commit after complete comparison. It does not wait for the other source to arrive.
Unsupported conclusion: timeout or absence means no payment
The unknown result may belong to accepted provider work. It does not authorize another charge, immediate fulfillment or release of a payout reserve.
Check next: the original receipt and business delivery
Payment and fulfillment are separate records. The caller checks delivery under the original business identity to avoid duplicate shipment or entitlement grants.
Expose investigation facts without taking over the ledger
Authorized inquiry selects originals by account, application, state and creation time, and returns separate lifetime CNY and USD totals for successful collections and payouts. Exact integer totals increment once per successful original. They are neither balances nor net settlement after fees. Operator views omit payer link credentials and recipient identity.
Verification concerns include exact-original comparison, notification/query races, one-time summary changes, persistence failure after provider acknowledgement and lawful restart recovery. The SDK also requires the application’s independently stored declaration when interpreting receipts and payouts. Missing, mismatched or unavailable evidence grants no fulfillment or reserve-release decision.