Payment controls and records

One order, three reference numbers

Keep the store order number as the order reference, then attach each provider identifier under its actual object name. Use the store number for order support, the PaymentIntent for the Stripe payment flow, the Charge for later refund or dispute investigation, and the Checkout Session for the hosted checkout journey. Add any case reference separately. These identifiers are connected records, not interchangeable names. Establish the connection from records you can open; a matching amount and time are clues, not enough to declare a match.

For: Owners and operations staff of research-only stores who need a repeatable way to connect store orders with provider payment records.

Updated 2026-10-01

Get help with checkout

Start the map while ordinary orders are still easy to trace

Choose where the team will keep its internal reference map and who maintains it. Begin with real orders in the payment paths you actually use. Record the store name or domain, order number, gateway name and the provider account context visible to an authorized user. This prevents a bare order number from being mistaken for an order in another store or a provider entry in another account.

WooCommerce's troubleshooting guide says to identify the payment gateway on the order or in its notes. A gateway transaction reference is the bridge to inspect next. Preserve the label exactly: a field called transaction ID does not establish whether its contents identify a PaymentIntent, a Charge or an object from another provider. Confirm the object in the provider record before classifying it.

Leave a reference unconfirmed when it cannot be opened or its relationship to the order is absent. Do not manufacture the missing identifiers, assume every connector saves every object, or create another payment to fill the map. A useful standing map makes missing links visible before a refund or support deadline exposes them.

Keep the payment flow, the charge and the checkout journey separate

Stripe's payment-status guide explains that the Dashboard label summarizes the PaymentIntent status. The PaymentIntent tells you where the payment flow stands; it is useful when asking why payment still needs action, remains processing or awaits capture. Later refunds and disputes belong to the Charge. A PaymentIntent that reached succeeded therefore does not tell the whole later history of the payment.

A Checkout Session is another record. The captured Stripe API reference separates Session status from payment_status: a complete Session may still have payment processing underway. Keep its identifier for a checkout journey question and record those two fields separately if status matters. The reference examined uses API version 2026-08-26.preview; confirm the actual integration and version before assuming the same fields are exposed by your connector.

The title's three references are not a limit. Your real order may have fewer accessible identifiers or additional attempts and cases. Keep each observed relationship, including a superseded attempt, with its own date and outcome. Overwriting an earlier reference with the latest one makes the next investigator unable to tell which payment a past message discussed.

Quote the reference that answers the recipient's question

For the store team, lead with the store order number and the task: order contents, fulfillment, order notes or a customer message. For the integration maintainer, add the gateway's recorded transaction reference and the verified provider object it points to. That gives the maintainer both ends of the connection without sending the entire customer record.

For a Stripe payment-flow question, quote the PaymentIntent identifier and the exact status field you read. For a refund or dispute question, quote the linked Charge and any separate refund, dispute or case reference that the provider actually issued. A support case reference locates the conversation; it does not replace the underlying payment reference. Follow the provider's requested reference format and authorized support channel.

For a hosted-checkout question, quote the Session identifier and its link to the order where that relationship is established. Do not send the private checkout URL or a client secret as if it were the Session ID. Another provider may use different objects entirely; retain that provider's vocabulary.

Keep the map durable without making a second customer database

Record where each identifier was obtained, when the relationship was checked and who can retrieve the source record. Use the map to locate the live record again before money or goods move. A stored status is dated evidence, so a later refund, dispute or new attempt needs a new entry rather than reliance on an old snapshot.

Separate missing, not applicable and not accessible. A checkout path that does not use Checkout Sessions needs no invented Session ID. An identifier absent from the store notes may still need investigation by the authorized integration owner. If a payment may already exist, WooCommerce warns against asking for another attempt until the gateway confirms the first created no charge.

For a Prism checkout consultation, describe which connection is missing and which platform and gateway are involved. Keep the filled map in your own controlled records; the public inquiry needs the problem, not the customer history or payment credentials. Confirm scope, responsibilities, fees and terms before any work.

Reference map

Use one copy for each real order and retain separate entries for distinct payment attempts. In the blank column, record the identifier, source location and date verified, or mark missing, not applicable or not accessible. Keep the filled map internal; never enter card data, secrets or private payment URLs.

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.

Reference map. The last column is for temporary notes.
ReferenceWhere to establish the linkWhich conversation it helpsYour verified record
Store order numberThe named store's order record, with the gateway identified on the order or in its notes.Order support starts here; the number alone does not identify a Stripe object.
Gateway transaction ID in order notesCopy the gateway's exact field label and inspect the corresponding authorized provider record.Give the maintainer both the order and this bridge; mark the object type unconfirmed until verified.
PaymentIntent IDThe verified Stripe payment-flow record connected to that order or attempt.Questions about payment action, processing or capture state; retain the exact status field name.
Charge IDThe linked Stripe Charge record, with its connection to the payment confirmed.Later refund and dispute questions require the Charge history, even when the PaymentIntent succeeded.
Checkout Session IDThe real Session for this checkout path; distinguish status from payment_status.Hosted-checkout journey questions. Do not substitute a checkout URL or client secret.
Dispute or provider case referenceThe actual dispute entry or support reply, associated with the Charge and order.A dispute reference identifies a payment case; a support ticket identifies a conversation. Label which one it is.
Additional attempt or later eventThe additional provider record and its dated relationship to this order.Retain the earlier reference so staff do not refund, discuss or retry the wrong attempt.

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

  • Not every gateway exposes all these identifiers. Missing access or a missing mapping does not establish that no payment exists.
  • Stripe object names and the captured Session API-version scope do not define another provider's records.
  • The map establishes traceability, not payment approval, fulfillment permission or merchant eligibility. Keep customer records and credentials out of the public consultation form.

Related guides

Sources

  • Payment status updates — checked 2026-09-21. The Dashboard summarizes PaymentIntent status; later refunds and disputes are recorded on the Charge. These are distinct records to identify in a reference map.
  • WooCommerce: Troubleshooting orders — checked 2026-09-21. Identify the gateway on the order or in its notes. Do not retry until the gateway confirms that the first attempt created no charge; missing notes can reflect missing gateway communication.
  • Checkout Session status and existing Customer prefill in captured API reference — checked 2026-09-29. In the captured API version, Session status is separate from payment_status, and complete can coexist with payment still processing. This supports keeping the Session and its fields distinct, not assuming connector coverage.
  • Prism solutions — checked 2026-09-21. Consultation scope, fees and terms are discussed before work; published support includes storefront review and help with provider website questions.

Get help with checkout

Is this happening on your own store?

Get help with checkoutAll resources