For: Anyone managing payment requests via Prommt.
Before you act: confirm it's actually a duplicate
The most important step — before doing anything else — is to confirm a genuine double charge has taken place. Customers sometimes report being charged twice when only one payment has gone through, or when a bank hold looks like a completed charge on their statement.
Do not issue a refund until you've confirmed both transactions are genuine completed charges. Refunds are irreversible in Prommt and issuing one on a false duplicate cannot be undone.
Step 1 — Check View Payments
Go to View Payments in your Prommt dashboard and search for the customer by name, email, or amount.
Look at the payment records:
If you see one record with a status of Paid — only one payment went through. What the customer is seeing is likely a bank hold, not a completed charge. See the section below on bank holds.
If you see two records both showing Paid for the same amount — a duplicate may have occurred. Note the Transaction IDs on both records before taking any action.
If one record shows Paid and another shows Failed — only one payment went through. The failed attempt will not result in a charge, though the bank may have placed a temporary hold.
Step 2 — Check the Transaction IDs
Open each payment record and note the Transaction ID on each. Two separate Transaction IDs confirm two separate gateway transactions — a genuine duplicate charge.
If both records share the same Transaction ID, or one is missing a Transaction ID, contact Prommt Support before taking any action — this needs investigation at the gateway level.
For help finding Transaction IDs, see How to find the Transaction ID for a payment.
Why duplicates happen
Understanding the cause helps prevent it happening again. The most common reasons:
The customer submitted the payment twice The customer may have clicked Pay more than once at checkout — for example, because the page appeared to freeze or they didn't see a confirmation screen. Most payment gateways have duplicate detection that blocks a second charge within a short window, but this doesn't always catch it.
A team member sent two payment requests Two separate payment requests were sent to the same customer — either intentionally (correct) or by mistake. Check View Payments to see if two distinct requests exist, sent at different times.
The customer was resent a request they'd already paid If a customer's payment wasn't immediately reflected in Prommt and a team member resent the request, the customer may have paid both. Always check the payment status before resending — a short delay between payment and status updating is normal and doesn't mean the first payment failed.
A back-office or PMS integration posted a second charge If your account is integrated with a back-office or property management system, a duplicate posting instruction from that system can trigger a second charge in Prommt. This is less common but worth checking if the duplicate requests appear to have been system-generated rather than manually sent.
What to do when a genuine duplicate is confirmed
Once you've confirmed two separate Paid records with two distinct Transaction IDs:
1. Do not issue a refund immediately without checking both sides Confirm with your team that only one payment was intended. If the customer legitimately made two payments (e.g. two separate orders), no refund is due.
2. Identify which transaction to refund In most cases, refund the most recent of the two — but confirm this with your team based on what was agreed with the customer.
3. Issue the refund from the correct payment record Go to View Payments, open the payment record you're refunding, and use the Refund button. See How to issue a refund for full steps.
4. Inform the customer Let the customer know a refund has been issued and the expected timeframe — typically 3–5 working days for card payments to appear back on their statement.
Bank holds vs. genuine duplicate charges
A common source of confusion: customers sometimes contact you reporting a double charge when what they're actually seeing is a bank hold alongside a completed charge.
This happens when a payment attempt fails after the card authorisation step but before the gateway confirms the transaction. The bank has reserved the funds (a hold appears on the customer's statement), but the charge was never completed — and the hold will release automatically, usually within 3–7 working days depending on the customer's bank.
How to tell the difference:
In View Payments: a bank hold scenario typically shows as one Paid record and one Failed record (or no second record at all)
On the customer's statement: a hold usually shows as a pending transaction, not a completed debit — though some banks display both identically
If the customer is insisting a charge has gone through but you can only see one Paid record in Prommt, ask them to confirm with their bank whether both amounts are completed debits or whether one is a pending hold. Do not issue a refund on a hold — it will release without any action on your part.
Preventing duplicates
A few practices that reduce the risk:
Always check the payment status before resending. A short delay between payment completing and the status updating in Prommt is normal — wait a few minutes and refresh before resending.
Don't send a new request while the original is still active. If the customer hasn't paid, resend the existing request rather than creating a new one. Cancel the original first if you need to correct an error.
One request per transaction. Avoid sending multiple requests for the same charge — if one needs to be corrected, cancel it before sending a replacement.
Check View Payments before actioning any customer query about a missing payment. Confirm the status before assuming a payment didn't go through.
Still not sure? Contact Prommt Support
If you can see two Paid records and aren't sure which represents the genuine charge, or if the Transaction IDs look unusual, contact Prommt Support before issuing any refund:
Chat: Use the chat button in your Prommt dashboard
Email: support@prommt.com
Include both Transaction IDs and the payment references — this lets us pull the gateway-level detail and confirm exactly what happened before you take any action.