Intents, Authorization & Capture
Intents, authorization and capture are the payment model where a durable server-side intent represents one checkout’s attempt to collect money, while authorization approves the funds and capture actually takes them. The intent lets a checkout survive refreshes, tab closes and retries without accidentally creating duplicate payment attempts.
The problem is that checkout happens across unreliable boundaries. A customer can refresh, close the tab, lose network, double-click submit, or return later from authentication. If each browser event creates a new payment attempt, the system can confuse recovery with a new purchase. Frontend state is especially fragile, so the checkout needs a durable record on the server that says, in effect, this cart is already trying to collect this amount.
Concretely, the backend creates or retrieves a payment intent when checkout begins, stores its identifier against the cart, order or checkout session, and gives the browser only the client secret needed to continue. The browser mounts the payment UI and confirms that same intent. If the customer comes back, the backend looks up the existing intent and returns its client secret again, rather than making a fresh payment object.
Authorization and capture describe different points in the money movement. Authorization means the payment method has approved a charge for the intended amount. Capture means the merchant finalises taking the money. Some checkouts do both immediately. Others authorise first and capture after stock checks, fulfilment or risk review. The intent is the object that records where this lifecycle has reached.
The trade-off is that your checkout state becomes backend-owned and must be carefully keyed. You need rules for when an existing intent is still valid and when a new one is required, such as a genuine cart, currency or order change. Reusing too aggressively can attach the wrong payment attempt to changed business state. Creating too freely can produce duplicate attempts and messy reconciliation.
Engineers meet this pattern when integrating hosted or embedded payment forms, especially with client secrets and webhook-driven status updates. A common misunderstanding is that every page load, form mount or submit click should create a new intent. It should not. The safer design is one reusable intent per unfinished checkout, with server-side lookup, idempotent creation and clear rules for replacement.
Common questions
- Is a payment intent the same thing as a charge?
- No. A payment intent is the stateful object representing the checkout’s attempt to collect money. A charge is closer to the resulting money movement once the payment is authorised and, depending on configuration, captured. The intent can move through several states before it results in a completed payment.
- When should I create a new payment intent?
- Create a new intent when the underlying checkout has genuinely changed, not merely because the page reloaded. Typical reasons include a changed cart, amount, currency or order identity. If the customer is returning to the same unfinished checkout, retrieve the stored intent and continue with it.
- Why send the client secret to the frontend instead of the intent identifier?
- The intent identifier is useful for your backend bookkeeping, but the browser needs a limited credential that allows it to confirm that specific payment attempt. The client secret serves that purpose. It lets the payment UI continue the checkout without exposing broader server-side privileges or requiring the frontend to create payment objects.