Example scope & report

# Stripe: recover an interrupted payment request

A proposed reliability review for an existing Payment Intents integration

[← All services](/services)

Public reference: Stripe. Independent example based on public documentation. Not commissioned by or affiliated with Stripe.

[Download all 7 reports (PDF) ↓](/examples/upserto-example-reports.pdf)[Download Markdown ↓](/examples/payment-reliability.md)

## Decision brief

Recommended next decision

| Question | Recommendation |
| --- | --- |
| Decision | Keep one durable order-to-payment identity through an interrupted request. |
| Why it matters | A missing response does not establish payment failure or justify a new instruction. |
| Acceptance | Lost responses, duplicates and reordered events resolve without a repeated fulfilment effect. |
| Scope boundary | Merchant application and its fulfilment contract; Stripe account, dispute and settlement decisions are excluded. |

## The proposed engagement

Proposed brief: an application already uses Stripe Payment Intents. A customer retries checkout after a network interruption, and support needs to determine which payment belongs to the order. Upserto would review order-to-PaymentIntent identity, request retries, webhook processing and fulfilment. The goal is a documented recovery path that does not create a fresh payment instruction merely because the application missed a response.

Inputs required. Payment code; API version; order-state model; redacted webhook samples; fulfilment contract.

## System boundary and assumptions

The reference is Stripe’s documented API v1 idempotency and webhook behavior. Stripe recommends Checkout Sessions for many new integrations; this example concerns improving an existing Payment Intents flow, not choosing the default for a new checkout. Review would cover the merchant application and its order database. Card handling, account eligibility, disputes and settlement are outside this slice.

## How Upserto would approach it

Identify the stable business operation before inspecting retries. Record which PaymentIntent belongs to the order and when the provider identifier becomes durable. Review signature validation on the raw body, duplicate event handling and allowed local transitions. Use Stripe test-mode fixtures and application failure injection only after scope and credentials are agreed.

## What the team would receive

- An order/payment state map and a provider capability checklist.

- A repair for the agreed retry or webhook boundary with focused tests.

- A reconciliation query and support runbook for unresolved operations.

An unknown outcome is a recovery stateThese are application recovery decisions, not Stripe’s complete status model. The order and original provider object remain linked throughout recovery.Solid: allowed decision path · Unknown does not authorize a new payment

Read the diagram- Persist the order-to-provider identity before handling retries.

- A missing response keeps the operation unresolved. Retrieve current provider state.

- Fulfil only after the application has authoritative evidence and its local transition is permitted.

## Starting point and proposed change

Items to inspect in the customer integration, the proposed control and the evidence needed for acceptance.

Design comparison

| Control | Inspect first | Proposed change | Acceptance evidence |
| --- | --- | --- | --- |
| Request retry | Check operation keys and provider mapping. | Stable order identity and documented provider retry rules. | Lost response resolves the original operation. |
| Webhook decision | Check duplicate and delivery-order handling. | Verified event, explicit transition and durable fulfilment key. | Duplicate and stale events do not repeat fulfilment. |
| Support recovery | Check whether retry and inspect are separate actions. | Read-only refresh plus owned reconciliation. | Support resolves an unknown without creating another instruction. |

## Decisions and approval owners

Decisions to agree before implementation

| Decision | Proposed default | Approval owner |
| --- | --- | --- |
| Retry policy | Reuse or retrieve the existing operation under the configured Stripe API contract. | Payments backend owner |
| Order completion | Agree which verified provider state permits fulfilment and who resolves conflicting evidence. | Product + payments operations |

## Review questions and implementation risks

P1 Resolve before releasing the affected workflow, or record an explicit acceptance decision. P2 Assign an owner and an agreed follow-up milestone; do not leave the item unowned.

### PAY-01 · P1 · Does a missing response create a new payment?

If retries generate a new business operation or idempotency key, the application can lose the connection between the original order and the provider request. This is a review question about the merchant code.

Proposed approach. Persist the order-to-provider mapping and apply Stripe’s documented idempotency rules for the exact API version. Do not assume API v1 and v2 cache failure results identically.

### PAY-02 · P1 · Can a repeated event fulfil an order twice?

Stripe documents duplicate events and does not guarantee delivery order. Local fulfilment must not rely on receipt order or a single delivery.

Proposed approach. Verify the raw payload signature, record event identity and enforce the allowed order transition with a durable uniqueness rule for fulfilment.

### PAY-03 · P2 · Who resolves a payment that remains unclear?

If the application cannot explain an order/provider mismatch, support may retry an action that creates another instruction.

Proposed approach. Provide read-only status refresh and a reconciliation queue. Record the operator decision and keep creation separate from inspection.

## Example technical output

Proposed merchant-side recovery logic

```text
operation = load_order_operation(order_id)
if operation.payment_intent_id:
  inspect_existing_payment_intent(operation)
else:
  create_with_persisted_operation_key(operation)
on_missing_response: mark_reconciliation_required()
on_verified_success: enqueue_fulfilment_once(order_id)
execution_result: TO_VERIFY
```

## Delivery plan and ownership

Proposed action plan

| Priority | Review item | Accountable role | Acceptance gate |
| --- | --- | --- | --- |
| P1 | PAY-01 | Payments backend owner | A lost-response fixture resolves the original order without a new unintended PaymentIntent. |
| P1 | PAY-02 | Backend + fulfilment owner | Duplicate and reordered fixtures produce one fulfilment instruction and no state regression. |
| P2 | PAY-03 | Payments operations | An aged unresolved order has an owner and a status refresh that cannot create a payment. |

## Acceptance checks

Run these checks before accepting the proposed changes.

Acceptance checks

| Scenario | Required evidence / expected behavior | Status |
| --- | --- | --- |
| Create response is lost | Original order maps to one intended provider operation | To verify |
| Webhook is delivered twice | One fulfilment instruction; repeat is a recorded no-op | To verify |
| Earlier state arrives after success | No local order-state regression | To verify |
| Support refreshes an unresolved order | Inspect only; creation requires a separate decision | To verify |

## Rollout and recovery

Confirm the existing API version and checkout flow before changing behavior. Add observation and reconciliation before automatic recovery. Exercise failure cases in the approved test environment, then release to an agreed merchant scope. Preserve the ability to stop new creation while continuing event processing and investigation for existing orders.

## Handover and limits

The handover would include code changes, test evidence, the state map and support steps for unknown outcomes. Test-mode results establish test-mode behavior only. Production acceptance requires authorized records linking the order, provider object and fulfilment effect.

## Access and evidence handling

Controls for the agreed engagement

| Area | Required control |
| --- | --- |
| Access | Use test-mode access and redacted event fixtures for the agreed merchant integration. |
| Evidence | Record order, event and provider-object references; exclude card data, secrets and raw personal details. |
| Production | Require a scoped approval before inspecting live records or changing payment behavior. |

## Public documentation used

The sources below establish product capabilities and API contracts. The implementation choices above are Upserto’s proposed approach for a customer integration.

- [Stripe: Idempotent requests ↗](https://docs.stripe.com/api/idempotent_requests)API v1 and v2 retry semantics differ; use the configured version.

- [Stripe: Receive events ↗](https://docs.stripe.com/webhooks)Signature verification, duplicate delivery and event-order guidance.

- [Stripe: Payment Intents ↗](https://docs.stripe.com/payments/payment-intents)Existing PaymentIntent lifecycle; documents Checkout Sessions recommendation for new integrations.

Discuss the same kind of work for your system, with an agreed scope and acceptance criteria.

[Explore Payment infrastructure and PSP integrations ↗](/services/payment-psp-integrations)[Discuss a similar scope ↗](/contact)

Contact: [hello@upserto.com](mailto:hello@upserto.com)