Offer express checkout

Express checkout puts wallet buttons, such as Apple Pay and Google Pay, on a store's product and cart pages. The shopper taps a button, picks an address and a delivery option in the wallet sheet, confirms, and is charged; the order is created without the checkout page. A payment app offers it by declaring it. The same signed charge request starts the attempt, and the platform reads the provider through the app’s status endpoint to decide whether the order is paid.

Add express to the payment declaration of your app's draft. It needs the charge operation, is frozen with the release like the rest of the declaration, and can be changed only by a new release. Without it, your app never receives an express charge and its connections never show buttons.

Saving a declaration refuses: express on a non-payment declaration (not_supported), express without charge (charge_required), an unknown express.adapter (unknown), a wallet the adapter cannot show (express.wallets unsupported), a currency that is not an ISO code or that the adapter does not accept (express.currencies invalid_currency, unsupported_by_adapter), and empty wallets or currencies (required).

A purchase whose total is outside the adapter's limits shows no buttons. Wallet sheet amounts are whole minor units; Tringify converts the exact order total and never rounds.

For each ready connection, add express_config to the connection check response: the public configuration the adapter needs for that merchant account. Its shape belongs to the adapter. fakepay_express takes exactly {"publishable_key": "pk_test_…"} (or pk_live_…), and the key's mode must match the reported mode.

An express charge is the signed request to your declared charge endpoint described in Accept a payment, with the same session_id idempotency, the same amount and currency_code (the order's outstanding total as an exact decimal string) and the same return_url (the order page). It adds express. shipping_address is absent when nothing ships; billing_address is the wallet's billing identity when the wallet gave one, else the shipping address.

Charge confirmation_token for exactly amount in currency_code, using session_id as the provider's idempotency key, on the connection named by connection_key. Never log the token and never keep it after the provider answered. Then answer:

A success carries exactly one express_status; launch_url only and always with requires_action; never browser_action. Tringify fails the session on any other shape. A normal charge to the same app (no express block) is answered with one browser handoff, as before.

express_status controls the browser handoff. Tringify reads status to record money: pending, paid with every captured payment, or failed with a reason. The app keeps no payment or refund outcome records and sends no result callbacks. Provider notifications wake the named attempt; scheduled platform checks provide correctness when notifications are missing. If a charge reply is lost, read the attempt at the provider before retrying creation with the same idempotency key. Late captures are still returned by status.

Tringify decides on every page and tells the merchant and the theme why (ctx.express.reason). The reasons that concern your app: no enabled, ready connection of an express app for the market (EXPRESS_REASON_NO_PROVIDER), a connection without express_config (EXPRESS_REASON_PROVIDER_SETUP), the market's currency not in your currencies (EXPRESS_REASON_CURRENCY), and a total outside the adapter's limits (EXPRESS_REASON_ORDER_LIMIT). The rest are store and purchase rules: the switch is off, checkout is unavailable, a required checkout field, sign-in required, pickup, an empty cart, a discount code, a gift card, a personalised or sold-out item. Only automatic discounts apply in the sheet. The merchant sees each express provider, its wallets, markets and readiness under Online Store → Preferences → Express checkout.

Fake Pay is a demo Stripe-like provider; no real money moves. Its Tringify app is the model for real wallet providers.

Fake Pay declares all five required operations: charge, status, cancel, refund and refund_status. Cancel answers the same status shape, including paid when already captured. Refund creation uses refund_id as a durable provider reference; refund_status reads it live. A repeat beyond the provider’s 24-hour HTTP cache returns that refund’s current outcome. Disconnecting or replacing credentials stops new charges on that account while retained credentials continue serving historical status and refunds until store-data erasure. The embedded app no longer has a payment-report attention list; payment failures belong to Tringify’s normal order and refund handling.