← All topic guides

Topic Guide

Payment Gateway Integration

Stripe and Authorize.Net are the two gateways this platform has actually shipped, and they don't share a flow shape. One expects your landing page to capture the charge. The other, Authorize.Net's DPM flow, settles before your page ever sees it. Build one handler and copy it for the other, and the failure is silent: no error, no exception, just a receipt that never generates or a transaction ID confused for an invoice number.

Every post here is a real integration bug or a real hardening decision from running both gateways in production. Some are pure debugging: a gateway callback that fed a raw POST field straight into a SQL WHERE clause, an x_trans_id treated as an invoice number because an OR fallback made them look interchangeable. Some are process: a tokenization feature that passed every sandbox test and then hit a vendor capability flag that was never enabled in production. One is a debugging technique worth stealing on its own, shipping a throwaway relay page to prod on purpose because a gateway won't POST to localhost.

The throughline: a payment gateway callback is still a public endpoint, sandbox passing is not proof, and the two flow shapes are not interchangeable no matter how similar the code looks.

8 posts in this guide, by DX

Start here

Stripe Needs a Post-Back, Authorize.Net Doesn't: One Page, Two Flow Shapes

Stripe expects your landing page to capture the charge; Authorize.Net DPM settled before the redirect. Copying one handler for the other fails silently in prod.

· 5 min read

The two flow shapes, and what breaks when you conflate them

A gateway callback is still a public endpoint

Debugging a gateway you can't run on localhost

Sandbox passing is not proof

Payment data and the systems built around it

Hitting one of these walls in your own codebase or your own machine? Talk it through with us, or read the rest of the Build Log.