In development. Payment capabilities have no recorded evidence yet. Use sandbox credentials only. See maturity levels.
- create and reset a provider test account
- keep server secrets in the deployment environment, out of
config.json
- expose a temporary HTTPS endpoint for provider events
- read the provider’s own event log
- throw away your Store’s test data afterward
Read How Connections route provider work before you test a refund. Refunds are where provider routing stops being an abstraction.
Install one provider
Install @86d-store/payments alongside exactly one provider Module:
Add both to your active Template’s config.json and regenerate:
One provider at a time. There is no safe failover between processors: a refund has to go back through whoever took the money, so a second configured provider buys you nothing and costs you a class of bug that is painful to find.
Stripe
PayPal
Square
Braintree
Register this endpoint in Stripe:Subscribe to the PaymentIntent success, failure, cancellation, and refund events your test exercises. The Stripe Module page has the package detail. The Storefront also needs NEXT_PUBLIC_PAYPAL_CLIENT_ID to render the PayPal button.Subscribe to capture completion and denial. See the PayPal Module. The Storefront also uses the public Square application and location identifiers.See the Square Module. Subscribe to the settlement events your test uses. See the Braintree Module. Test the event boundary
Provider events are the part that breaks in production and looks fine in a demo. Run all six of these before you widen testing:
- Send a valid test event. Confirm exactly one state change.
- Send an event with a bad signature. Confirm it is rejected, not merely logged.
- Send the valid event again. Confirm no duplicate effect.
- Deliver events out of order. Confirm state cannot move backward.
- Retry after an ambiguous write. Confirm the recovery is idempotent.
- Refund something. Confirm the refund went back through the Connection that took the Payment.
A green sandbox happy path is not evidence. The failure paths are the evidence.
Check the whole purchase, not the charge
A provider Module on its own does not give you a trustworthy path from Checkout to an Order. Verify the server-owned amount, Inventory, tax, Shipping, the Payment outcome, Order creation, and retry behavior together, because that is how they fail: together.
See How commerce records relate, Payments, and Checkout.
What 86d Payments will cost
86d Payments is a planned service. When it arrives, the fee on Launch and Premium will be:
5% of eligible merchandise subtotal, plus exactly $0.50 per paid Checkout.
That rate is all-in. It is your complete cost to accept the payment. No separate processor line reaches you, because upstream processing is paid out of the same fee.
Eligible merchandise is your subtotal after product discounts and Loyalty redemption. Shipping, tax, tips, and any order fee you define are excluded from the calculation.
Some specifics worth knowing before you model your margins:
- One fee per paid Checkout, created when confirmed captures first cover the full amount due. An authorization on its own creates no fee.
- Splitting a payment into several captures does not repeat the 50 cent charge.
- A void, a full refund, a cancellation you make, or a chargeback the buyer wins credits the entire fee back to you.
- A partial refund recalculates the fee against what is left. While merchandise remains, 86d keeps 5% of that remainder plus $0.50. When nothing eligible remains, no fee remains.
- A reversed refund or dispute outcome reverses the matching adjustment.
Launch and Premium share one published rate with no volume tiers. Enterprise rates are negotiated. Using 86d Payments does not waive the 86d Cloud management fee.
86d is not the merchant of record, does not sell chargeback protection, and does not insure you against fraud loss. Refund, dispute, and chargeback costs stay yours unless 86d caused the failure.
Selling before payments are switched on
A Store waiting on payment activation can retain a non-binding Checkout Request for 30 days. It stores the requested Products, quantities, contact details, and displayed estimate. It stores no Payment credential, reserves no Inventory, guarantees no price, and creates no Payment or Order.
If payments activate before the request expires, the Store may send one checkout invitation that expires no later than the request. Checkout recalculates price, Inventory, tax, and Shipping, then asks the Shopper to accept the fresh result and provide a Payment method. Payment finalization may hold Inventory for 15 minutes; success commits that lease, while cancellation, failure, or expiry releases it. The Store never collects a card for deferred capture before activation.
Related pages