Fidelidad del emulador de Stripe

Índice / Index · English

Original: docs/en/fidelity/stripe.md. Revisión del 2026-09-06 usando llms/stripe/llms.md. Es un índice de fuentes, con un OpenAPI oficial y checksum en contracts/stripe/; la validación sigue siendo un subconjunto manual.

#Fuentes

PaymentIntent, Refund, Link y apariencia de Checkout.

#Superficie

Crear y consultar /v1/payment_intents, confirmar, capturar y cancelar mediante sus sufijos, y devolver mediante POST /v1/refunds. Base: http://localhost:8080, prefijo /stripe opcional. El SDK oficial instalado stripe@22.6.0 acepta host, puerto, HTTP y telemetry: false. Idempotency-Key es opcional. Se admiten JSON y formularios codificados. La suite utiliza el SDK cuando se proporciona una base de datos.

#Qué se emula

• Crear sin cobrar o confirmar con confirm=true. La captura manual deja requires_capture antes del cobro separado.
• Secreto de cliente e IDs estables. Una autorización ya tiene latest_charge. automatic_async se conserva en la respuesta, con ejecución local síncrona.
• amount_received representa lo cobrado incluso después de devolverlo; no es el saldo neto. No se inventa amount_refunded en PaymentIntent.
• Cada devolución tiene ID e importe propios: varias parciales y devolución final del remanente.
• Se rechazan capturas inválidas, negativas, fraccionarias, enteros inseguros e importes superiores al autorizado.
• Errores del proveedor, idempotencia, contabilidad balanceada y outbox. El SDK verifica la firma HMAC y su tolerancia temporal.
• Checkout local con resumen izquierdo, tarjeta derecha, adaptación móvil y datos de tarjeta de muestra no editables. IDs técnicos y rechazos deliberados quedan en bloques secundarios. Autorizar no se presenta como cobrar.

#Estados

Creado y fallido: requires_payment_method, con error en el segundo caso. Acción del comprador: requires_action. Autorizado: requires_capture. Cancelado: canceled. Capturado, liquidado, devuelto y disputado: succeeded.

Completar un checkout de captura manual solo autoriza; el comercio debe capturar después. API y checkout comparten el bloqueo del pago.

#Qué no se emula

• OpenAPI completo ni negociación de versiones; aceptar campos no demuestra compatibilidad completa.
• Elements, Checkout Sessions, PaymentMethods, tokenización, entrada real de tarjeta, 3DS o tarjetas guardadas. El resultado no depende del medio; incluso se puede confirmar sin el medio que exigiría una integración real.
• Link y ACH no se ofrecen en el checkout. Link guarda medios de pago y tiene autenticación propia; no es saldo interno. Faltan OTP, mandatos y liquidación ACH.
• Otras operaciones de actualización. Los campos payment_method, receipt_email, return_url y el motivo de cancelación ya se conservan al consultar.
• Webhooks completos: recurso mínimo, tipos de recurso en devolución/disputa y eventos de devoluciones parciales aún incompletos. Firmar no valida el contenido.
• Devoluciones por charge, consulta/historial y estados asíncronos. Se resuelve solo por payment_intent.
• Actualización, listas, expand, Charges, Customers, SetupIntents, Disputes, BalanceTransactions y Payouts.
• Tarifas y tiempos reales. 2,9 % + 0,30, dos días de liberación y 15,00 por disputa son parámetros sintéticos. automatic_async no implica captura asíncrona real; la liquidación se realiza mediante un barrido local.