A buyer changed methods while the first payment was still pending
Check every recorded attempt linked to the order, including the first method, the second method and any cancellation outcome. Copy each provider's current state and the time checked. Selecting another method does not establish that the first payment was canceled. An asynchronous payment can still resolve later, so one owner must reconcile those later outcomes with the order and its existing fulfillment record. Do not request another payment while an existing charge may exist.
For: A research-only merchant reconciling one order after a buyer selected another method while an earlier payment remained unresolved.
Map the attempts before interpreting the latest selection
Begin with the existing order and its payment notes. Record the gateway and reference for the first attempt, then the gateway and reference for the later attempt. Check whether both refer to the same order or whether the method switch also left a second order record. The latest method label on the store screen is not a complete history of what was submitted.
Open the corresponding records in the authorized provider accounts. Keep account, mode, amount, currency, creation time and current state associated with each reference. A method change need not produce two separate payment objects, so do not invent a second identifier when the integration reused an existing flow. Conversely, one order number does not establish that there was only one provider payment.
If a reference is missing, document the account and period searched and leave the attempt unresolved. A buyer's choice of method tells you what they selected; it does not prove which requests the integration sent or which payments the providers accepted.
Read processing and cancellation as provider states
Stripe's PaymentIntent lifecycle explains that asynchronous processing can take days. That is a reason to inspect the state of the first attempt even after the buyer used another method. It is not a deadline for this particular payment or evidence that every method stays pending for the same period. Preserve the exact status and the time you read it rather than shortening every unresolved state to failed.
For a Stripe PaymentIntent, requires_confirmation is a confirmation stage and differs from requires_action. Failed attempts can return to requires_payment_method. Read these as states of the existing flow, not as proof that selecting a new method canceled every earlier request. If the provider is different, use its own state definitions rather than applying Stripe's names.
Look for a cancellation result that identifies the actual payment. A requested cancellation, a canceled store order or a buyer leaving checkout is not the same record as a provider-confirmed canceled intent. Stripe says canceled intents cannot be reopened, while method-specific exceptions govern cancellation during processing. Do not assume an in-progress payment is cancelable or that a submitted cancellation request succeeded.
Make one fulfillment decision from the reconciled states
If both attempts remain unresolved, neither a second selection nor a return-page message establishes a paid order. Keep fulfillment awaiting reconciliation under the store's actual release policy. If the later payment is confirmed while the earlier one is still processing, identify which payment supports the release decision and who continues following the earlier attempt. The unresolved payment must stay visible even if the order is released once.
If both provider records show successful payments for the same obligation, assign the financial reconciliation to the authorized payment owner. Do not create a second shipment because another success arrived, and do not initiate a refund merely because two references exist. The owner must establish what each record represents and any prior action before choosing a remedy through the appropriate provider.
For hosted Stripe Checkout Sessions, Stripe's fulfillment guidance requires checking payment status and using webhook events; the return page alone is insufficient, and an unpaid session is not fulfilled. Those rules describe that hosted flow. A WooCommerce gateway or another integration needs its own documented release behavior, compared with the order notes and provider records. WooCommerce warns against retrying until the gateway confirms that the first attempt created no charge.
Keep later outcomes attached to the same order
A pending map is unfinished until the unresolved outcomes have been reconciled or explicitly handed to an owner. Record the existing success or failure notification, the payment reference it concerns and whether the store recorded it. For delayed hosted Checkout methods, later asynchronous success or failure events require handling. A later event for the first method must be assessed against the second payment and any fulfillment already performed.
Keep payment ownership and fulfillment ownership explicit. The payment owner follows remaining payment states and any authorized financial correction. The fulfillment owner records whether the order was held or released and the existing shipment reference. If the integration acts on both attempts, the maintainer needs the actual references and event history to determine whether its behavior could release the same order again. The worksheet does not authorize a code change or a replay of payment requests.
For a Prism checkout consultation, describe the two methods, the recorded status conflict and the point where ownership or integration behavior is unclear. Keep full payment records in the authorized systems and agree any diagnostic, implementation or follow-up scope, responsibilities, fees and terms before work. A consultation does not guarantee cancellation or a particular settlement outcome.
Multiple-method pending map
Use one map for the real order and retain each attempt's provider reference in your authorized internal records. Read all rows before a fulfillment decision. A later successful payment does not erase an earlier unresolved attempt; assign someone to reconcile its eventual outcome.
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.
Multiple-method pending map. The last column is for temporary notes.
Order or attempt detail
Evidence to read
Decision or open dependency
Your record
Order reference
Evidence to readExisting order, amount, currency and any additional order created during the method change.
Decision or open dependencyEstablish the obligation being paid and check whether it has already been fulfilled.
First method and state
Evidence to readGateway, account, mode, payment reference, exact provider status and time checked.
Decision or open dependencyPreserve an unresolved asynchronous payment; do not translate processing into canceled or failed.
Second method and state
Evidence to readThe later provider record, or the existing flow if no separate object was created.
Decision or open dependencyDetermine whether it confirms payment for this order and whether it is distinct from the first attempt.
Known cancellation record
Evidence to readProvider result tied to the specific payment, with time and outcome.
Decision or open dependencySeparate a request from a confirmed cancellation; method changes and store cancellation labels are insufficient.
Later outcome and store receipt
Evidence to readExisting success or failure notification for the unresolved payment and corresponding order note.
Decision or open dependencyCheck whether that result was reconciled with the other payment and any previous release.
Fulfillment owner
Evidence to readNamed release decision, payment supporting it and existing fulfillment reference if released.
Decision or open dependencyRecord hold or release under the actual policy and prevent an additional payment outcome from being treated as another order.
Outstanding payment owner
Evidence to readPerson responsible for the remaining state, financial discrepancy or missing provider result.
Decision or open dependencyKeep the case assigned after shipment if necessary; do not request a further payment while a charge may exist.
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.
Limits
Cancellation availability and processing duration depend on the provider and payment method. No universal cancellation window or irreversible-settlement rule is implied.
Stripe hosted Checkout fulfillment guidance applies to Checkout Sessions, not automatically to every store extension that uses Stripe.
This comparison does not authorize a retry, cancellation, refund or second shipment. Keep card data, authentication codes, payment-link tokens, credentials and full bank details out of worksheets and public inquiries.
PaymentIntent and SetupIntent lifecycle — checked 2026-09-29. Asynchronous PaymentIntent processing can last days; cancellation has method-specific exceptions. requires_confirmation differs from requires_action, failed attempts can return to requires_payment_method, and canceled intents cannot be reopened.
Stripe Checkout fulfillment — checked 2026-09-21. Hosted Checkout fulfillment checks session payment status and webhook events rather than relying on the landing page. Unpaid is not fulfilled, and delayed methods have later asynchronous success or failure outcomes.
WooCommerce: Troubleshooting orders — checked 2026-09-21. Identify the gateway on the order or its notes, reconcile provider payment with store state, and do not retry until the gateway confirms the first attempt created no charge.