Start with the payment method and gateway recorded on that order, then read its gateway notes and follow the transaction reference to the matching provider record. Confirm the account, amount, currency and payment state there. A plugin being enabled today, a familiar checkout label or an express button does not establish who processed an earlier order. WooCommerce permits WooPayments and its Stripe plugin together, but documents duplicate express buttons and similar checkout labels as possible problems. Attribute existing payments before deciding which overlapping choices to retain; coexistence alone does not prove duplicate charges or damaged records.
For: A research-only merchant or authorized WooCommerce administrator whose store has two active card-payment integrations.
An enabled-methods list describes the store's current configuration. The order's payment-method record describes the integration associated with that order. Those facts may agree, but a plugin added or changed since the purchase cannot explain the historical payment by its presence alone. Begin from the order even when one plugin seems the obvious choice.
WooCommerce's guidance specifically says WooPayments and the WooCommerce Stripe plugin can coexist and that doing so is almost never necessary. It identifies duplicate express-checkout buttons and similar payment labels as the practical issues. That guidance is about this pair of integrations. Two similarly named card choices are a reason to inspect their ownership, not proof that both integrations charged the customer.
Follow the order reference into the payment record
WooCommerce's order-troubleshooting guide directs you to identify the gateway on the order or in its notes. Read the notes in time order, keeping the gateway name, any payment reference and the reported action together. A note about authorization and a note about a completed payment need different follow-up; the presence of a reference alone does not establish capture.
Open the corresponding record using authorized access to the provider or payment service named by that integration. Compare its reference with the order, then check the amount, currency and timestamp as supporting evidence. If the provider exposes order or integration metadata, compare what is actually present. Do not assume every plugin writes a standard metadata field, and do not treat an order number or amount alone as a unique match across accounts.
Attribution is complete only to the extent the evidence agrees: this integration, this account, this payment and this recorded payment state. If the order names one gateway but the available payment record belongs to another, preserve the disagreement. Check the references and historical configuration rather than changing the order to make the labels agree. If the provider shows only authorization, record that no capture has yet been established.
Missing notes and connection indicators have limits
WooCommerce says missing order notes can mean the gateway did not communicate with the store. Missing notes therefore do not establish that no payment exists. Its troubleshooting guidance also warns against asking the buyer to pay again before confirming that the earlier attempt created no charge. A second payment through the other plugin is not a way to discover which one handled the first attempt.
The WooCommerce Stripe extension connects a Stripe.com account and separately reports Payment, Payout, Webhook and Sync status in its account details. Those indicators describe the connection; they do not attribute a historical payment. Do not disconnect, reconnect or create another account to answer an order-history question. Use the existing records and the appropriate authorized account access.
For that extension, WooCommerce's documented support covers installation, connection, webhooks and checkout behavior. Stripe handles Stripe account and Dashboard questions. Give the relevant owner the narrow unresolved issue: a missing order-to-payment reference, a payment state the store failed to record, or an account record you cannot locate.
Standardize the buyer choices after attribution
Make a separate inventory of the methods enabled in each plugin, their checkout labels and the express buttons they supply. Compare that inventory with the checkout that is actually configured. Decide whether each overlap serves a documented purpose or presents an indistinguishable choice to the buyer. Intentional coexistence can remain a valid store design; it still needs clear ownership and records.
Before authorizing removal of a method or plugin, list open orders and historical payment work that may still depend on it, including payment updates and refund handling. Have the maintainer establish those dependencies from the installed integration's documentation and records. This page does not establish that deactivation is harmless or required. Keep the account-to-order mapping accessible whichever future checkout choices you select.
A Prism checkout-review consultation can start with the two plugin names, the observed overlap and the part of attribution that remains unresolved. Describe the symptom without sending customer exports, payment credentials or private dashboard links. Agree scope, responsibilities, fees and terms before work. Neither an enabled integration nor a consultation establishes provider approval for a research-only business.
Gateway attribution sheet
Complete the historical-order rows for one real order before using the current-configuration rows to plan cleanup. Keep internal references in authorized records and write a redacted match finding here. Conflicting or missing references mean attribution remains unresolved; they do not justify another payment attempt.
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.
Gateway attribution sheet. The last column is for temporary notes.
Record
What to inspect
Decision supported
Your finding
Order payment-method line
What to inspectThe method and gateway actually named on the affected order, with its order date.
Decision supportedIdentifies the recorded integration, rather than the plugin you currently prefer.
Gateway order notes
What to inspectThe gateway's messages, payment reference and whether each note describes an authorization, failure or payment result.
Decision supportedShows what the integration reported. Missing notes leave a communication question, not proof of no charge.
Provider account and payment
What to inspectA matching payment reference in the correct authorized account, supported by amount, currency and timestamp.
Decision supportedEstablishes where the payment resides and whether capture is recorded; amount alone is not sufficient attribution.
Existing payment metadata
What to inspectAny order or integration reference the provider record actually exposes; record absent if none is present.
Decision supportedCorroborates the match without assuming every integration writes the same fields.
Each plugin's enabled methods
What to inspectThe current plugin names, versions, connected-account labels and methods enabled within each.
Decision supportedDescribes today's overlap. It cannot prove the configuration at an earlier purchase date.
Labels and express buttons
What to inspectWhich integration owns each similar label or duplicate button visible on the configured checkout.
Decision supportedIdentifies a buyer-facing ambiguity without inferring a duplicate charge.
Dependencies before cleanup
What to inspectOpen orders, historical payment updates and refund tasks, plus the maintainer's evidence about dependencies.
Decision supportedSets the scope of any proposed method or plugin change; do not disable from appearance alone.
Attribution conclusion
What to inspectIntegration, account and payment state confirmed together, or the exact missing or contradictory reference.
Decision supportedA confirmed match supports a specific support handoff. An unresolved match stays open without another charge.
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
WooCommerce's coexistence guidance covers WooPayments and its Stripe plugin; another pair needs its own integration evidence.
Duplicate labels or buttons do not prove duplicate capture, inevitable record corruption or a need to disable either plugin.
Do not retry a payment, change accounts or disconnect an integration to establish attribution. Keep credentials, card data and customer records out of public inquiries.
WooCommerce: WooPayments and the Stripe plugin together — checked 2026-09-21. WooPayments and the Stripe plugin can coexist, although WooCommerce says it is almost never necessary. Documented issues include duplicate express buttons and similar checkout labels, not inevitable record corruption.
WooCommerce: Troubleshooting orders — checked 2026-09-21. Identify the gateway on an order or in its notes. Missing notes can indicate failed communication; reconcile a provider charge with the order and do not retry before confirming no charge exists.
Connecting WooCommerce to Stripe — checked 2026-09-29. The Stripe extension connects a Stripe.com account and separately displays Payment, Payout, Webhook and Sync status. WooCommerce handles extension questions and Stripe handles account and Dashboard questions; connection status does not attribute an earlier payment.