A newly enabled payment method needs later outcome notifications

Identify the integration before choosing event names

Record the provider, account connection, actual payment method and checkout product used for the store. Include the installed gateway or extension and its version where relevant. A method appearing in checkout does not establish that every required downstream event has an owner. Confirm the method’s eligibility for the disclosed business separately with the provider; technical availability is not that decision.

The event names here belong to hosted Stripe Checkout Sessions. They are not a universal recipe for every Stripe plugin, Payment Element integration or another provider’s bank method. If the installed integration uses a different payment object or callback model, ask its maintainer for the required outcome events under that model before interpreting coverage. Do not add unrelated event subscriptions simply because this page names them.

Map completion, later success and later failure separately

For hosted Stripe Checkout, checkout.session.completed records checkout completion. With a delayed method, the payment can still be unresolved. Stripe’s fulfillment guidance requires checking the session payment status; an unpaid session must not be fulfilled. The buyer reaching the return page is also insufficient, because a successfully paying buyer might never reach that page.

The later Checkout outcome events are checkout.session.async_payment_succeeded and checkout.session.async_payment_failed. Record the handler and intended store action for each. Success handling needs to connect the payment outcome to the same order and apply the fulfillment decision with the payment-status check. Failure handling needs to preserve the failed outcome and identify the owner of any buyer communication or next order action. A failure notice is not authority to create a fresh charge.

Treat an existing immediate-payment path as only evidence for that path. Seeing orders progress after checkout completion does not establish what happens when a delayed payment succeeds or fails later. The missing outcome is a distinct coverage question, even if the checkout itself looks unchanged.

Check subscription, handling and saved result as separate evidence

Stripe event destinations select the account scope and event types they receive. Compare the required event list with the destination actually connected to this store. A correct event name subscribed on another account connection does not establish delivery to this order integration. Record the destination and connection without copying its signing secret.

For each outcome, obtain the maintainer’s explanation of which handler processes the event and which order reference it uses. A configured subscription does not prove that the application handles the event. Likewise, an endpoint’s 2xx response acknowledges delivery, not the completion of a later order update. Where existing real records are available, connect the event, delivery attempt, handler result and saved order state.

Stripe documents duplicate and out-of-order delivery. Ask how the existing integration avoids repeating fulfillment and how it prevents an older event from overwriting a later state. These are coverage questions for the implementation owner, not instructions to replay live events. If no real later-failure record is available, distinguish documented handling from behavior observed in orders. Do not invent a transaction or call the failure path verified.

Make the coverage decision from the open gaps

You can now identify whether the gap is an event absent from the destination selection, a selected event without confirmed handling, or handling without a traceable saved result. Give the integration owner that exact gap. If the provider still reports the payment as unresolved, the pending order may reflect the payment’s real stage; changing the store label would not settle it.

Before relying on the method to drive order state, obtain a defined action and responsible owner for completion, later success and later failure. Missing coverage remains unresolved. This page sets no settlement deadline and does not authorize sending another payment request, changing subscriptions or enabling a method on an unapproved account.

A Prism checkout consultation can start from the platform, method and outcome whose handling is unclear. Describe the work you need and the evidence already available. Prism will confirm scope, responsibilities, fees and terms before work begins; the inquiry alone does not include integration changes or establish provider eligibility.

Payment-method event coverage

Complete a separate sheet for each actual delayed method and integration. For every outcome, distinguish configured delivery, documented handler behavior and behavior observed in existing real orders. Keep an unobserved outcome unverified. Use internal references without secrets or customer payloads.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.