A customer found an old payment link

Identify the object behind the old message

Start with the message or store record that originally issued the request. Record the request type, creation date where available, associated order and provider reference. Keep the actual private URL in its authorized source location. Do not paste its tokens into a worksheet or public inquiry, and do not submit a payment to find out whether it still works.

Stripe describes an invoice as a request to collect from a specific customer that cannot be reused for another customer. It describes a Payment Link as usable by anyone who has the link. A forwarded reusable link therefore cannot be treated as a request restricted to the person who first received it. Its existence also does not identify which buyer, Session or order a later payment belongs to.

A Checkout Session is a particular checkout record with its own status and payment_status. Treat its expiry as a fact about that Session, not the lifetime of every payment request that may lead to checkout. A WooCommerce order-payment URL is a store payment path to investigate against its order and gateway; do not apply Stripe Session or invoice meanings just because it also arrives as a link.

Keep unknown request types unresolved until the authorized store or payment owner can identify them. This is a lifecycle investigation of an existing request, not a reason to create another invoice or change the business's approved payment rail.

Read payment state before deciding what the link permits

In the captured Stripe Session reference, open means checkout is still in progress and payment processing has not started; expired means no further processing will occur for that Session. Complete means the Session is complete but payment processing can still be underway. Those definitions come from the API reference captured at version 2026-08-26.preview; confirm the version and connector used by the actual store.

The separate payment_status field distinguishes paid, unpaid and no_payment_required. The last of those is not proof that an ordinary paid merchandise order has been funded. Inspect the Session mode and the actual order before interpreting it. If a Session is complete but unpaid, do not label the order paid or ask the buyer for another payment while the first outcome remains unresolved.

Stripe's hosted-flow guide describes creating the Session, redirecting to the hosted page and handling the resulting completion event. The integration still has to connect that result to the store order. A buyer opening the old link or returning to a page does not show that this connection happened. Compare the provider payment state with the linked order before changing fulfillment.

For an invoice, inspect that invoice's customer, payment record and remaining amount actually shown. For a store payment URL, inspect the order, gateway notes and provider record. Neither the invoice's old issue date nor the fact that a payment page opens establishes an unpaid balance. WooCommerce's troubleshooting guidance warns against retrying until the gateway confirms the first attempt created no charge.

Compare the paid offer with what the business can fulfill

Stripe's hosted Checkout guide documents line items supplied through Price references or explicit price data when a Session is created. Therefore inspect the items, quantities, amounts and currency on the actual payment request and resulting order; the current product page alone cannot tell you what that request contained. Do not assume editing or retiring a catalog page updated a previously issued payment request.

For a paid order, compare that recorded offer with availability, the customer's actual agreement and the business's current ability and permission to supply it. If the order can be fulfilled as agreed and the payment is confirmed, route it through the authorized fulfillment process after reconciliation. A retired listing does not by itself prove that an already paid order must be canceled.

If the paid offer cannot be fulfilled, record the reason and use the business's authorized customer-resolution and refund process. Match any refund to the actual payment and retain its provider outcome beside the order. Removing a link or marking a store order canceled does not demonstrate that money was returned. A price change alone also does not authorize collecting an extra amount or silently substituting a product.

If the request is unpaid and the old offer should no longer be available, have the authorized owner use the platform's documented process for retiring or canceling that request. Resolve any pending payment first. Issue a current replacement only after its items, price, customer scope and relationship to the original are established; retain the old reference so support does not confuse the two.

Retire the request and reconcile the order as separate tasks

Give each obsolete request an owner and record what was changed, when and in which system. Separately record the outcome for every payment or order already associated with it. A change that prevents future use does not settle prior payments; a refund on one order does not establish that a reusable payment request can no longer be used.

For a reusable link shared beyond its intended audience, review the link's current configuration and the actual orders resulting from it. Do not classify every resulting order as valid merely because payment succeeded, or as invalid merely because the link was forwarded. Assess the recorded offer and the business's order controls. Provider eligibility remains a separate condition from technical link availability.

The completed table should identify which request needs retirement, which order can proceed and which payment or customer decision is still unresolved. For a Prism checkout consultation, describe the stale-request type and the mismatch between the offer and the order. Confirm scope, responsibilities, fees and terms before work; omit private links, customer records and payment secrets from the public form.

Session-state table

Use the matching row for each real request. In the blank column record its internal reference, observed status and time, linked order, responsible owner and chosen next action. Do not enter the private URL or its tokens. Treat retiring the request and resolving an existing payment as separate completion checks.

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.