Stripe emulator fidelity

Índice / Index · Español

Reviewed on 2026-09-06 using llms/stripe/llms.md. The LLM file is a discovery index. The official OpenAPI snapshot and checksum now live in contracts/stripe/. Validation still covers a selected handwritten subset.

#Sources

• PaymentIntent.
• Refund.
• Link.
• Checkout appearance.

#Surface

Base URL: http://localhost:8080; /stripe is optional. The installed official stripe@22.6.0 SDK accepts host, port, protocol: 'http' and telemetry: false. Idempotency-Key is optional. Form-encoded and JSON bodies are accepted. The integration suite exercises the SDK when a database is supplied.

#What is emulated

• Creation without an attempt, or immediate confirmation with confirm=true. Manual capture confirms to requires_capture and then captures separately.
• A stable client secret, PaymentIntent identity and synthetic charge ID. An authorized payment already has latest_charge. automatic_async is preserved in the response but executes synchronously in the emulator.
• amount_received is the collected amount, including after refunds. It is not the net balance. amount_refunded is not invented on a PaymentIntent.
• Refund responses have their own ID and the amount of that individual refund, including multiple partial refunds and a final refund of the remainder.
• Invalid, negative, fractional and unsafe-integer capture amounts are rejected; the shared runtime also rejects capturing above the authorized amount.
• Provider-shaped errors, idempotent execution, balanced ledger and transactional outbox. The SDK verifies the Stripe-Signature HMAC and timestamp tolerance.
• A local checkout with merchant summary on the left, a card form on the right, mobile stacking and read-only test-card details. Technical IDs and deliberate rejection controls are secondary. Authorization is not displayed as a charge.

#State vocabulary

Created and failed map to requires_payment_method, with an error on failure. Buyer action maps to requires_action; authorization to requires_capture; cancellation to canceled. Captured, settled, refunded and disputed intents remain succeeded.

Manual checkout completion now authorizes without collecting money. Its later capture uses the same intent lock as buyer completion and refunds.

#What is not emulated

• No version negotiation or full schema validation. Partial handwritten validation and permissive fields do not establish full API compatibility.
• Elements, Checkout Sessions and PaymentMethods are missing. The buyer page is a local simulation, not Stripe.js or a hosted Checkout Session. There is no tokenization, genuine card input, 3DS, saved card or payment-method-dependent outcome. Creation/confirmation may succeed without the payment method required by a real integration.
• Link and ACH are not offered by the checkout. Link saves funding methods and uses its own authentication; it is not the emulator's internal wallet. Neither Link OTP nor ACH mandates and delayed settlement are implemented.
• Confirmation payment_method, receipt_email, return_url and cancellation reason now survive retrieval. Other update operations remain unsupported.
• Webhook payload fidelity is incomplete. Notifications contain a minimal resource stub; refund/dispute event resource types and partial-refund events are not fully modeled. Signature verification alone does not validate payloads.
• Refund lookup is limited to payment_intent. Charge-based lookup, refund retrieval/history and asynchronous refund states are missing.
• Update, list, expand and other resources are not implemented. This includes Charges, Customers, SetupIntents, Disputes, BalanceTransactions and Payouts.
• Accounting and timing are synthetic. 2.9% + 0.30, two-day release and 15.00 dispute fee are simulation defaults, not a verified tariff. automatic_async does not introduce real asynchronous capture; settlement is a local sweep.