Charged twice or seeing a pending authorization? How to tell
Discuss with AI
Opens an AI with a question about the public article URL. Check its answer and sources.
The page must be published. Access and prefilled text are not guaranteed; copy the prompt if needed. Only the public URL and this prompt are passed along.
Two entries in a banking app do not automatically mean two completed payments. Match each entry to the provider’s payment and capture records, then compare the underlying invoices. Correct a genuine duplicate; explain a pending hold or separate purchase with the records that establish the difference.
In this article
When a customer reports being charged twice, first determine whether there are two captured payments for the same obligation. Two lines in a bank app may instead include a pending authorization, a failed attempt, or two separate purchases. The right next action depends on which of those records actually exists.
Compare the payment records before the screenshots
Ask for the amounts, currencies, dates, displayed merchant names, and whether each entry is pending or posted. Use an appropriate support channel for any screenshot and ask the customer to hide unrelated transactions. Do not request a full card number or security code to investigate recognition of a charge.
Search your payment provider for the relevant records, then identify the invoice or order each belongs to. Record the payment IDs and actual status. Matching amounts and dates are useful search clues, but they do not establish that two records paid the same invoice.
Stripe separates authorization from capture: an eligible payment can reserve funds before they are captured. Its PaymentIntent object exposes status and separate capturable and received amounts. Those distinctions are more informative than the number of entries in a support screenshot.
Classify what the customer is seeing
Scroll sideways to see every column.
| Observed records | Working interpretation | What to verify |
|---|---|---|
| Two captured payments, one invoice | A potential completed duplicate | Whether both really settle the same obligation and whether a refund already exists |
| One captured payment and an uncaptured authorization | A payment plus a hold | Which authorization remains open and what the provider permits |
| A failed attempt followed by success | A retry sequence | Actual received amounts rather than attempt count |
| Two captured payments, different invoices | Possibly distinct purchases | The separate service, account, period, and agreement behind each invoice |
The table is an investigation model, not a set of provider status names. Confirm the live records before using any row in a customer reply. In particular, a failed application request does not prove the provider failed to create a payment; inspect the provider result.
Check renewals, upgrades, and multiple accounts
Subscription billing can produce similar-looking payments with different purposes. Compare the covered service periods, plan changes, seats, add-ons, and account IDs. A second email address or workspace might explain another invoice, but the existence of another account does not itself justify the payment.
If the extra amount follows an upgrade, downgrade, or seat adjustment, use the plan-change reconciliation guide to connect the approved change with invoice lines, credit, and collection.
Reconstruct what each invoice bought. If both payments are valid, a useful explanation names the separate purchases and includes their receipts. “They have different IDs” only proves they are separate records, not that both were owed.
If the same person appears across several accounts, use explicit account-to-payment links. The identity-resolution guide explains why a shared email address is a search aid rather than sufficient proof that every charge belongs to the same purchaser.
Correct the confirmed duplicate once
For an actual duplicate, check existing refunds and whether a dispute is open before choosing the provider-supported correction. Assign one owner so a support reply and a finance action do not each trigger reimbursement.
Stripe’s duplicate-dispute guidance asks merchants to distinguish separate purchases or show an existing refund. If the customer has already disputed one payment, follow that case’s instructions and deadline. Do not treat a generic refund as a substitute for the response required on the live dispute.
For an authorization hold, explain the verified state and the relevant provider guidance. Avoid promising that every bank will remove the entry on a fixed date. Retain the authorization identifier and the result of any cancellation or capture action.
Investigate the retry that created the confusion
Illustrative example. A €29 renewal request times out in the application. An operator clicks retry, creating a second payment with a new request identity. Both payments succeed against the same invoice. The initial timeout is not evidence that the first payment failed; the two provider success records establish the duplicate that needs correction.
Stripe documents idempotency keys for safely repeating API operations after connection errors. Engineering should inspect how the business operation maps to those keys rather than assuming every button click represents a new purchase. This is a prevention review, separate from resolving the customer’s existing payment issue.
Finish the support case with a factual statement: which payment completed, which was a hold or duplicate, what correction was confirmed, and what remains pending. If the customer cannot locate an issued refund, continue with refund reconciliation rather than sending another payment without checking the first.
Two identical amounts can belong to a genuine duplicate or to different subscription periods. Evidenz is being built around the records B2B and B2C SaaS teams need to tell those stories apart: the personal account or company workspace, invoice period, plan change, retry sequence, and any support or refund commitment. That context makes the correction explainable. A team can state which business event each payment concerns and why one requires action, rather than relying on different IDs or a count of attempts. The financial correction follows the verified provider records.
Sources and scope
Sources checked
Published by Evidenz. Examples are illustrative, not customer results. Check current requirements and the actual case against the linked sources.