Stripe Payments on AWS

## Stripe + AWS in 2026

Stripe is still the most developer-friendly way to take money on AWS. The architectural pattern has not changed much — Stripe holds PCI scope, AWS holds order state and fulfillment — but the specific Stripe building blocks have. In 2026 the important pieces are the **Optimized Checkout Suite**, **Adaptive Acceptance**, **Radar 2025**, **Issuing**, **Financial Connections**, **Terminal Cloud**, and the **Stripe Apps** marketplace.

This guide covers the architecture we recommend, the security posture we enforce, and the common pitfalls we see.

## What's new for Stripe + AWS in 2026

- **Optimized Checkout Suite** — Payment Element + Link + Express Checkout Element + Stripe's conversion optimizations, consolidated.
- **Adaptive Acceptance** — ML retry and network-tokenization logic to recover soft-declined transactions.
- **Radar 2025** — updated fraud ML, richer signals, more granular rules, integration with Stripe Identity.
- **Stripe Issuing** — virtual and physical card issuance programmatic APIs, now widely deployed for spend-management SaaS and marketplaces.
- **Financial Connections** — bank account linking + balance checks; cheaper ACH and smarter BNPL underwriting.
- **Terminal Cloud** — cloud-first in-person payments; fewer custom middleware boxes.
- **Stripe Apps** — embeddable Stripe-side apps (e.g., pulling Salesforce data into the Stripe Dashboard) and your own AWS-hosted apps surfaced inside Stripe.
- **Enhanced network tokens** — lower card-art churn for recurring payments.
- **PCI DSS 4.0.1** — effective during 2024-2025, affects payment-page scripts, MFA, and targeted risk analyses.

## Reference architecture

```
Browser (Stripe.js + Payment Element / Express Checkout Element)
  │  card data goes direct to Stripe — never to your AWS
  ▼
Stripe API (3DS / SCA / Adaptive Acceptance / Radar)
  │  payment_intent.succeeded (webhook)
  ▼
API Gateway (HTTP API)  ───▶  Lambda (webhook handler)
                                │  verify Stripe-Signature (Secrets Manager)
                                │  idempotency on event.id (DynamoDB)
                                ▼
                         EventBridge (payment.succeeded rule)
                                │
             ┌──────────────────┼──────────────────┐
             ▼                  ▼                  ▼
   Step Functions         SES / SNS           Salesforce / HubSpot
   (fulfillment)          (receipt)           (Platform Event / webhook)
             │
             ▼
     DynamoDB or Aurora DSQL (order state)
             │
             ▼
     Datadog APM / Security Lake (OCSF)
```

- API Gateway HTTP API is the cheapest webhook receiver.
- Put the webhook Lambda on provisioned concurrency if traffic is spiky — cold-starts cause Stripe retries.
- Use DynamoDB as the idempotency store; `event.id` is the primary key.
- Fan out with EventBridge, not synchronous calls.
- Keep Stripe secrets in AWS Secrets Manager with rotation on (yes, even the webhook signing secret — Stripe supports rolling signing secrets).

## Implementation (5 steps)

See the structured **How to** above for the five-step flow: create a PaymentIntent from Lambda → collect with Payment Element → confirm client-side → handle the webhook with signature verification and idempotency → persist and fan out via EventBridge.

## PCI DSS scope with Stripe

- **With Stripe.js / Payment Element**: PCI DSS SAQ A (ecommerce outsourced). Your scope is order data, accounts, and AWS infrastructure — not card data.
- **PCI DSS 4.0.1** (effective 2024-2025): tighter script-integrity rules for payment pages, stronger MFA, targeted risk analyses. Practical AWS controls: CSP and SRI for scripts on payment pages, IAM Identity Center + MFA for AWS console access, CloudTrail retention per policy, and MFA for Stripe Dashboard users.
- **Without Stripe** (direct PAN handling): full Level 1 audit, QSA engagement, quarterly ASV scans — we strongly recommend staying on SAQ A.

## Fraud and authorization

- **Adaptive Acceptance** is on by default. Leave it on; pair with Radar so you are not retrying transactions you want declined.
- **Radar rules**: block on high-velocity attempts, disposable email domains, and device/IP mismatches. Radar for Fraud Teams adds rule editor + block/allow lists + score explanations.
- **Network tokens**: improve authorization on recurring charges; Stripe handles token lifecycle automatically.
- **3D Secure (SCA)**: required in EU/UK; Stripe orchestrates challenges when risk warrants.
- **Stripe Identity + Financial Connections**: add identity and bank verification for high-risk flows (marketplaces, BNPL underwriting, Issuing KYC).

## Money movement primitives

- **Charges / PaymentIntents** — one-off card or wallet payments.
- **Subscriptions (Stripe Billing)** — with metered billing, tiered pricing, and revenue recognition.
- **Connect** — marketplaces and platforms; split payments and payouts to connected accounts.
- **Issuing** — create virtual and physical cards programmatically; authorize or decline on a webhook.
- **Financial Connections** — bank linking, balance checks, ACH at 0.8% capped at $5.
- **Treasury** — embedded banking-like features for Connect platforms.
- **Terminal Cloud** — in-person payments without a custom middleware box.

## When Stripe is NOT the right call

- Hard regulatory requirement for a specific on-prem or local-region acquirer that Stripe does not support in your country.
- High-volume enterprise with an existing direct-acquiring contract where you can negotiate interchange-plus pricing significantly better than Stripe's blended rate — revisit only above $10M/yr.
- You need a merchant-of-record model (tax and chargeback liability outsourced) — look at Paddle or Lemon Squeezy instead, or use Stripe Billing + a tax provider.
- B2B invoicing-only with wire / ACH and very low volume — a simple RDS + SES pipeline may be cheaper than Stripe Billing.

## Stripe vs Adyen vs Braintree vs direct acquirer

| Dimension             | Stripe                              | Adyen                                    | Braintree (PayPal)            | Direct acquirer                 |
| --------------------- | ----------------------------------- | ---------------------------------------- | ----------------------------- | ------------------------------- |
| Best fit              | Online-first, developer-led teams   | Omnichannel enterprise, EU+APAC strong   | Marketplaces with PayPal core | $50M+ volume, IC+ pricing power |
| Pricing model         | Blended (2.9% + $0.30)              | Interchange++ or blended                 | Blended                       | Interchange-plus, contract      |
| PCI scope             | SAQ A with Payment Element          | SAQ A with Drop-in / Components          | SAQ A with hosted fields      | SAQ D / Level 1 typical         |
| Auth optimization     | Adaptive Acceptance + Smart Retries | Network tokens, RevenueAccelerate        | Account Updater               | Build it yourself               |
| Local payment methods | 100+ via Payment Element            | 250+ deepest in EU/APAC                  | Limited beyond US/EU cards    | Per-acquirer arrangement        |
| Issuing / banking     | Stripe Issuing + Treasury           | Adyen Issuing                            | Limited                       | None                            |
| Time to first charge  | Hours                               | Days–weeks                               | Days                          | Months                          |
| AWS ergonomics        | Excellent (this guide)              | Good (similar webhook + Secrets pattern) | Good                          | Custom build                    |

Default to Stripe until volume + economics justify a multi-PSP setup. Above ~$10M/year, evaluate Adyen as a primary alternative or as a second processor for routing optimization.

## Failure modes & resilience

The PaymentIntent → webhook → fan-out path has six failure modes worth designing against explicitly.

**1. Webhook signature mismatch.** Caused by stale signing secret after rotation, mismatched test-mode/live-mode secrets, or a proxy/CDN modifying the body. Handler must return `400` (not `5xx`) so Stripe stops retrying. Alarm on a high `400` rate; rotate signing secret with overlap and update Secrets Manager before flipping the live endpoint.

**2. Lambda timeout / 5xx.** Stripe retries non-2xx responses with exponential backoff for ~72 hours. Verify `webhook.Lambda.errors` is auto-recovering — repeated 5xx without success shows a real bug, not a transient. Always return `200` after persisting `event.id` to the idempotency store; offload synchronous work to EventBridge so the handler is sub-second.

**3. Idempotency-key collisions across re-deploys.** DynamoDB `event.id` PK with TTL ~30 days is the safest approach. Never key on a synthesized hash that includes a deploy SHA — Stripe replays must hit the same lookup. For `Idempotency-Key` headers on outbound `POST /v1/payment_intents` calls (rate-limit recovery), keep a UUID per business request, retry the same key for up to 24 hours.

**4. Network partition between checkout and webhook.** Browser receives `payment_intent.requires_action` (3DS) → user completes challenge → Stripe sends `payment_intent.succeeded` webhook, but your endpoint is unreachable. Stripe will retry; meanwhile your UI must NOT mark the order paid based on `stripe.confirmPayment()` alone. Treat client-side state as optimistic; the webhook is authoritative.

**5. Stripe API rate limits.** Default ~100 read / 100 write requests per second per account. Bulk migrations (Issuing card creation, refund campaigns) will hit this fast. Strategy: outbound calls via a Step Functions DistributedMap with `MaxConcurrency: 50`; retry on `429` with `Retry-After` honored; raise via Dashboard when expected sustained volume exceeds the default.

**6. Smart Retries vs custom dunning.** For Stripe Billing recurring charges, Smart Retries uses ML to pick optimal retry timing — leave on by default. Add custom dunning logic only when you need region-specific cadence (e.g., regulatory delays in DE/FR), product-aware messaging in retry emails, or grace-period business rules Smart Retries cannot express. Switching them off later requires backfilling subscription state — decide before launch.

## Observability runbook

**CloudWatch alarms we ship by default:**

| Alarm                                                   | Threshold                        | First action                                                                       |
| ------------------------------------------------------- | -------------------------------- | ---------------------------------------------------------------------------------- |
| `webhook.Lambda.Errors`                                 | `> 0` over 5 min, 2/2 datapoints | CloudWatch Logs → grep error → confirm signing-secret rotation status              |
| `webhook.Lambda.Duration p99`                           | `> 3000 ms` over 15 min          | Trace in X-Ray; check DynamoDB latency, EventBridge PutEvents throttle             |
| `webhook.dlq.ApproximateNumberOfMessagesVisible`        | `> 0`                            | SQS console → message body → Stripe Dashboard event ID lookup → replay via redrive |
| `webhook.Lambda.Throttles`                              | `> 0`                            | Bump reserved concurrency; check Region-level Lambda concurrency cap               |
| `payment_intent.succeeded` event count vs 1h baseline   | drop `> 50%`                     | status.stripe.com → checkout health → upstream payment-method failures             |
| Stripe `decline_rate` (custom metric from event stream) | `> 8%` rolling 30 min            | Radar dashboard → review Adaptive Acceptance recoveries                            |

**Debug path: "Stripe Dashboard shows succeeded, our DB has no order":**

1. Stripe Dashboard → Developers → Events → search by `event.id`. Confirm webhook delivery attempts and their HTTP responses.
2. CloudWatch Logs Insights on `/aws/lambda/stripe-webhook`:
   ```
   fields @timestamp, @message
   | filter @message like /evt_xxxxxxx/
   | sort @timestamp desc
   ```
3. DynamoDB idempotency table: `aws dynamodb get-item --table-name stripe-events --key '{"event_id":{"S":"evt_xxxxxxx"}}'`. If present but order missing, fan-out failed downstream.
4. EventBridge archive: replay the succeeded event into a quarantine bus and walk the rule targets.
5. If signature verification failed, re-fetch the secret from Secrets Manager and confirm `version_stage=AWSCURRENT` matches the Stripe Dashboard signing secret.

**Tracing.** Enable X-Ray on API Gateway and Lambda; add `event.id`, `payment_intent.id`, and `customer.id` as annotations so single-trace lookups work in incident response.

## Pricing

| Payment type               | Rate                                     |
| -------------------------- | ---------------------------------------- |
| US card (standard)         | 2.9% + $0.30                             |
| International card         | 3.4% + $0.30                             |
| ACH direct debit           | 0.8% (cap $5)                            |
| Klarna / Afterpay / Affirm | 5.99% + $0.30 (varies by method/country) |
| Stripe Tax                 | 0.5% (min $0.05)                         |
| Stripe Link                | Included                                 |
| Radar for Fraud Teams      | Metered per transaction                  |
| Stripe Issuing             | Per-card + per-transaction fees          |

Verify the latest rates at [stripe.com/pricing](https://stripe.com/pricing). Volume pricing available for $1M+/year.

## Best practices

**Security**

- Stripe keys in Secrets Manager; rotate regularly and on any suspected exposure.
- Webhook signature verification on every call, without exception.
- CSP and subresource integrity on payment pages (PCI DSS 4.0.1).
- Separate test-mode and live-mode keys; separate webhook endpoints.

**Reliability**

- Idempotent webhook handlers keyed by `event.id`.
- Return 2xx within a few seconds; offload via EventBridge + Step Functions.
- CloudWatch alarms on Lambda errors, throttles, p99 duration; DLQ on failure.
- Reserved concurrency so the webhook Lambda is not blocked by other functions.

**Conversion**

- Use the Payment Element; enable Stripe Link; enable Apple Pay / Google Pay via the Express Checkout Element.
- Use Stripe's recommended payment-method ordering (on by default).
- Soft-decline recovery with Adaptive Acceptance.
- Network-tokenized recurring charges.
- Local payment methods in EU/APAC markets.

**Compliance**

- PCI SAQ A annually; retain attestation.
- MFA on Stripe Dashboard and on all AWS IAM Identity Center users.
- Quarterly access reviews on both sides.
- Event Monitoring + CloudTrail correlated in Security Hub / Security Lake.

## Related reading

- [`PCI DSS on AWS architecture guide for fintech`](/blog/pci-dss-compliance-aws-architecture-guide-fintech/)
- [`Cost-optimized SaaS stack on AWS, end to end`](/blog/cost-optimized-saas-stack-aws-end-to-end/)
- [`AWS Lambda cost optimization: pay-per-request vs provisioned`](/blog/aws-lambda-cost-optimization-pay-per-request-vs-provisioned/)

## Related services

- [AWS Application Modernization](/services/aws-application-modernization/)
- [AWS Cloud Security](/services/aws-cloud-security/)
- [AWS Serverless](/services/aws-serverless/)

Browser (Stripe.js + Payment Element / Express Checkout Element)
  │  card data goes direct to Stripe — never to your AWS
  ▼
Stripe API (3DS / SCA / Adaptive Acceptance / Radar)
  │  payment_intent.succeeded (webhook)
  ▼
API Gateway (HTTP API)  ───▶  Lambda (webhook handler)
                                │  verify Stripe-Signature (Secrets Manager)
                                │  idempotency on event.id (DynamoDB)
                                ▼
                         EventBridge (payment.succeeded rule)
                                │
             ┌──────────────────┼──────────────────┐
             ▼                  ▼                  ▼
   Step Functions         SES / SNS           Salesforce / HubSpot
   (fulfillment)          (receipt)           (Platform Event / webhook)
             │
             ▼
     DynamoDB or Aurora DSQL (order state)
             │
             ▼
     Datadog APM / Security Lake (OCSF)