# Pay and complete payment authentication

**Flow key:** `payment-and-3ds`

## Outcome

The intended amount is authorized or captured exactly once using a test payment method, with truthful challenge, decline, retry, refund, and reconciliation state.

## Actors

- Payer
- Application
- Payment processor
- Issuer/3DS provider
- Fraud controls

## Preconditions and entry points

- Use only processor-provided test methods.
- A synthetic payable order/intent exists.
- Authorization/capture/refund policy and webhooks are observable.

## Required test data

Use synthetic, isolated, resettable data. Never use real credentials, payment instruments, private customer records, or production notifications.

| Data | Canonical valid seed | Critical variations |
|---|---|---|
| Payment intent | test intent for `$30.00 USD` | zero, large, multi-currency, changed amount, expired |
| Methods | processor success token | decline, insufficient funds, expired, 3DS required, wallet |
| Authentication | successful test challenge | cancel, fail, timeout, browser closed, out-of-band completion |
| Network | normal | slow, offline after click, response lost after processor commit |
| Webhook | signed success event | duplicate, delayed, out of order, invalid signature |

## Canonical steps

Treat this as the ordinary successful path inferred from common product behavior. Adapt it to observed labels, business rules, APIs, and implementation evidence; do not invent a requirement.

| Step | User or system action | Expected evidence |
|---:|---|---|
| 1 | Create or retrieve the payment intent for the authoritative amount. | Intent binds order, customer, currency, amount, and idempotency key. |
| 2 | Collect payment using processor-hosted/tokenized controls. | Raw secrets do not enter application logs, DOM, analytics, or servers beyond scope. |
| 3 | Submit payment once. | The processor receives one intended attempt and returns a truthful state. |
| 4 | Complete 3DS or other step-up if required. | Challenge origin, amount, merchant, cancellation, and return state are trustworthy. |
| 5 | Process synchronous result and signed webhook. | Order/payment state converges despite duplicate, delayed, or out-of-order events. |
| 6 | Retrieve receipt and reconcile processor records. | Amount, fees, authorization/capture, refunds, customer, and order match. |

## Alternate paths

- Immediate capture
- Authorize then capture
- 3DS challenge/frictionless
- Wallet or bank redirect
- Partial payment/store credit

## Failure and recovery paths

- Decline then retry
- Timeout after authorization
- Challenge canceled
- Webhook delayed/duplicated
- Capture succeeds but order update fails

## Completion oracle

- The stated outcome is true in visible UI and authoritative persisted state.
- Exactly one intended business result and no unintended side effect occurred.
- Identity, tenant, authorization, money/data, lifecycle, notifications, integrations, analytics, and audit agree where applicable.
- Refresh, retry, back/forward, and a second authorized read do not reveal a contradictory result.
- Any partial, delayed, canceled, failed, or unknown outcome is labeled truthfully and has a safe recovery path.

## Evidence to capture

- Entry context, actor, tenant, role, feature flags, locale, time zone, and initial identifiers/state.
- Step-level screenshots or DOM state plus request/response, correlation, job, event, and stable business IDs where available.
- Before/after authoritative records, versions, totals, permissions, lifecycle states, and downstream side effects.
- Notifications, audit events, integration deliveries, retries, deduplication, latency, and recovery evidence.
- Untested branches, unsafe-to-run cases, product decisions, and evidence tier.

## Product decisions to resolve

- Exact eligibility, required data, authorization, and validation rules.
- Which steps are synchronous, asynchronous, optional, skippable, reversible, or irreversible.
- Idempotency, concurrency, timeout, retry, cancellation, and compensation semantics.
- Retention, privacy, notification, audit, performance, accessibility, and localization commitments.

## Related CARBON items

- [payment](../../items/records/payment.md)
- [currency price totals](../../items/data/currency-price-totals.md)
- [security](../../items/quality/security.md)
- [concurrency and idempotency](../../items/quality/concurrency-and-idempotency.md)

[Back to Commerce and billing flows](index.md)
