5 min read
Multiple Payment Providers: Separate Duplicate Customers From Duplicate Revenue
Merging customer records and removing repeated payments solve different problems.
· Grometrics Team
The short version
A business can collect payments through Stripe and another provider, or move customers between billing systems. A combined report can then contain several records for one person. That does not mean every payment is duplicated. Grometrics approaches revenue attribution by keeping the customer connection and the transaction evidence distinct. Before removing anything, establish whether the apparent duplicate represents another customer record, another real payment, or another delivery of an event already handled.
- Use customer identity to explain who paid and transaction identity to explain what happened.
- Keep provider and account context with external identifiers.
- Reconcile migrations separately from repeated event delivery and genuine repeat purchases.
Start with three different cases
The first case is one person with two provider customer records. The second is one person making two legitimate purchases. The third is the same payment being reported more than once. These cases can look similar in a spreadsheet sorted by email and amount, but they require different treatment. Removing a row because the amount and customer name match can erase a real payment while leaving the underlying identity problem unsolved.
Build a small reconciliation table that names the provider, provider account, transaction reference, customer reference, occurrence time, amount, and currency. Keep private customer values within the systems authorized to hold them. The purpose is to establish the relationships, not to distribute personal data into another document. An operator should be able to trace any reported amount back to an actual provider transaction.
Do not use email as universal proof
Email can be useful supporting context, but addresses can change, be shared, or differ between checkout and an app account. A match should follow the identity rules of the application and the evidence supplied by the payment provider. Do not merge unrelated people merely because a normalized text field matches. Where your own authenticated account identifier is available, document how each provider customer record was connected to that account.
External identifiers also need context. Keep the provider and relevant account with the identifier rather than treating every customer reference as globally unique across the business. This is particularly important during account migrations or when several connected billing accounts exist. A string that looks the same in two systems does not establish that the records represent one customer or one transaction.
Recognize repeated delivery without deleting legitimate activity
Stripe documents that webhook events can be delivered more than once and that event ordering is not guaranteed. A receiving system needs a durable way to recognize work it has already completed. This is different from deciding that two separate transactions belong to one customer. Keep the original transaction facts and the provider event relationship available when explaining why a repeated delivery did not create another payment.
Consider an illustrative USD 30 purchase reported twice after a delivery retry. The business has USD 30 of payment activity, not USD 60. Now consider the same customer buying another USD 30 product a week later with a different transaction reference. The business has two payments totaling USD 60. Similarity in customer and amount is not enough to choose between those situations. The responsible payment records must establish the difference.
Treat billing migrations as their own reconciliation
When a subscriber moves between providers, record what actually transferred. A migrated subscription record is not necessarily a new sale. A new provider customer record is not necessarily a new acquired customer. If a payment genuinely occurs during the move, retain it with its real provider and date. If a migration imports old history, preserve the historical dates and distinguish the import from a new customer visit.
ChartMogul describes customer and subscription merging as part of handling billing changes. That illustrates an important buying criterion, but do not assume every analytics tool applies identical migration rules. Review the tool's current behavior for the exact providers involved. Before a migration, define how new customer counts, churn, subscription continuity, and source attribution should behave, and reconcile those outcomes rather than judging success from a single revenue total.
Keep source attribution accountable
A valid customer merge can connect payment history to a known person. It still does not prove an acquisition source if no source was observed. Preserve the actual visit or installation evidence used for attribution, including its time. Do not copy the most recent campaign across every older payment simply because the records now share a customer identity. Identity continuity and historical acquisition facts are separate responsibilities.
Use a weekly exception review for unexplained repeats, unresolved customer connections, and migrations that change customer counts unexpectedly. Resolve each exception against the provider record and the application's identity history. The desired outcome is straightforward: every genuine payment contributes once, every customer count follows a stated rule, and every attributed source can be explained from saved evidence rather than inferred from convenient similarities.
Sources and further reading
READY TO SEE YOUR REAL NUMBERS?
Connect your payment provider and see which channels actually drive revenue.
Start tracking for free →RELATED POSTS