Authorization, preauthorization and 3DS

Authorization can refer to the customer’s permission to charge or the issuer’s approval of a particular transaction. Both matter and neither replaces the other. A merchant needs valid consent and must submit each payment under the applicable rules.

Authentication, consent and approval are separate

3DS, or 3-D Secure, helps the issuer establish whether the legitimate cardholder is involved. It can be frictionless or require a code or banking-app confirmation. It is a different step from transaction authorization.

Agreeing to terms does not guarantee issuer approval. Successful 3DS can still be followed by a balance, limit or risk decline. The absence of a challenge screen does not mean 3DS did not occur.

A preauthorization holds funds before capture

Hotels and car rental are common examples where the final amount is initially unknown. Approval reserves available funds or credit; the business later captures the relevant amount, and unused holds may be reversed or expire.

Check permitted use cases, validity periods, incremental authorization, partial capture and amount tolerances. Do not display a hold as a final expense or promise immediate balance release after a reversal. Issuer release timings differ.

A captured transaction commonly needs a refund, while an uncaptured authorization may be eligible for reversal. Choose the operation using the actual state and provider rules, rather than issuing reversals, refunds and retries at the same time.

Recurring payments need clear consent

Before the first payment, explain the merchant, price, frequency, trial conversion, cancellation and subsequent charges. Keep verifiable consent. Distinguish cardholder-initiated transactions (CIT) from merchant-initiated transactions (MIT) and supply the required references and stored-credential indicators.

Consent to store a card and consent to future charges can be different permissions. Repeated manual charges are not a sound substitute for a subscription flow, and cancellation must be respected.

Send accurate information and store less

Merchant details, amount, currency, billing data and transaction context should match the real order. Use supported SDKs, hosted checkout or tokens. Validate server notifications rather than trusting a successful return page in the browser.

Do not store CVV/CVC after authorization. Restrict access to full card numbers and personal data, and use masked data and correlation identifiers in logs. Confirm the applicable PCI DSS scope and sensitive-data requirements with the provider.

3DS cannot cover every dispute

Liability shift can apply to some eligible fraud disputes, depending on the network, region, authentication result, transaction type and rules. It is not immunity from every fraud, non-delivery or service-quality dispute.

When authorization fails, use the actual reason and retry guidance. Complete additional authentication when required. For hard declines, offer another card or a conversation with the issuer. Query unknown results before another attempt instead of generating duplicate charges.

Continue with the card payment system and fraud, disputes and chargebacks. Stripe’s official documentation is a starting point for the current card-data, authentication and integration rules of its products.