A Payment Approval Is Not a Fraud Verdict. It Is One Institution’s Timed Decision.
Authorization, authentication, merchant fulfilment and liability are four different things, joined too often by a dashboard label called approved. The article builds the evidence chain that lets an issuer, acquirer and merchant tell a good approval from a defensible payment.
The rule
An approval proves only the decision it records; preserve the evidence needed for every later question.
The Green Tick Has an Extremely Small Job
The most dangerous word on your payment dashboard is approved.
It arrives with a green tick.
The eye then concludes that the merchant has been paid.
That the customer has been identified.
That the goods went out.
That the account was not compromised.
And that somebody, somewhere, performed the moral equivalent of a criminal investigation.
A great deal of institutional optimism, compressed into six letters.
An approval is much narrower than that.
It records one institution’s decision, at one time, about one submitted transaction, on the information then available.
It may be an excellent decision.
It is not a verdict on identity, fulfilment, fraud or liability.
Those are separate questions.
They have separate evidence.
Eventually they have separate people from Risk, Operations, Merchant Services and Legal, sitting rather carefully around one table.
This is not an argument against approval.
It is an argument against asking a small green tick to perform unpaid work in four departments.
Your issuer decides whether an account and a presented credential may support a transaction for a stated amount, merchant and time.
Your acquirer submits the transaction.
Your merchant may later show what was ordered and delivered.
The network’s rulebook governs shared procedure.
Law, your account contract and the scheme rules decide which loss is reimbursable.
Or reversible.
Or recoverable.
Or merely regrettable.
That all of this begins with a request and an approval does not make it one fact.
The distinction becomes useful at precisely the moment somebody says, “But it was approved.”
Authentication Is Evidence of a Credential, Not a Biography
At card-not-present checkout, EMV 3-D Secure sends transaction, payment-method and device information from your merchant to your issuer.
The issuer authenticates the purchaser, then decides on authorisation.
A serious control.
Also a very specific one.
It establishes something about the credential and the authentication journey.
It does not establish that the person behind the credential was undeceived, uncoerced, or having an ordinary afternoon.
Your issuer holds card status, historic spend, previous authentication and cross-merchant patterns.
Your merchant holds product type, basket value, account age, email history, delivery choice, address consistency, device signals and prior use of the customer profile.
They are not holding duplicate records.
They are looking at different parts of the same event.
A low-risk returning customer moves through a frictionless flow.
A new order for easily resold goods gets challenged, or reviewed.
That difference proves nothing about either buyer.
It is a decision about the evidence you held before the order was accepted.
Either customer may later dispute.
Either order may later ship.
The machine has not acquired hindsight merely because its response was fast.
So separate the two verbs.
Authentication asks whether a presented credential or challenge result can be accepted.
Authorisation asks whether that credential may order this payment, to this merchant, for this amount, at this time.
A valid authentication result can coexist with an account takeover, a customer-authorised push-payment scam, or an order the merchant cannot later show was fulfilled.
Awkward outcomes.
Not logically inconsistent ones.
The Approval Record Needs a Chaperone
Do not store approved = true.
That is not a payment record.
It is a future meeting with a perfectly legible agenda and no useful attachments.
For every disputed approval, keep ten linked fields: credential; authentication result; device or channel; merchant identity; amount; authorisation time; approval code; clearing record; fulfilment evidence; dispute disposition.
A complete chain, not a tasting menu.
The credential and the authentication result address the presented identity.
Device or channel says how the event arrived.
Merchant identity, amount, authorisation time and approval code preserve the exact decision.
The clearing record links that decision to the submitted transaction.
Fulfilment evidence answers what happened after you accepted the payment.
Dispute disposition says what you finally decided, and under which process.
Each field needs its own time.
An authorisation time cannot be replaced by a later clearing date.
A clearing record cannot be inferred from an approval code.
A shipment scan cannot establish the original credential.
A dispute disposition cannot turn your merchant’s representation into your issuer’s authentication result.
All records of real things.
They simply belong to different chapters of the same administrative novel.
Payment state deserves the same adult supervision.
A reserve makes funds unavailable while no receiving institution holds a funded claim.
Your customer ledger can show a debit before interbank settlement.
A message can be queued, cleared, settled, credited, rejected, returned, or still unresolved.
In a credit transfer, the buyer’s reserve prevents double spending and gives the receiving bank no claim. After final settlement, a request to return funds is not a unilateral reversal.
The same discipline applies to any dashboard trying to turn pending, posted, available and final into synonyms because the interface likes clean lines.
A Fulfilled Order Is Not an Issuer Fact
Your merchant’s case begins exactly where the issuer’s authorisation record stops.
It holds the order, the delivery choice, the shipment or access evidence, and evidence of use.
For digital goods in a card-absent dispute, Visa guidance treats a successful download plus at least 2 specified data elements as an example of compelling evidence.
An IP address with device geographical location.
A device ID.
Not a magic incantation.
An evidentiary design, for a particular programme and channel.
So the issuer’s authentication result and the merchant’s fulfilment record complement one another.
Neither replaces the other.
A subscription with nothing but an approval response leaves your merchant badly placed to explain whether a profile linked to the disputed card ever used the service.
A delivery record tells your issuer nothing in return.
Not whether a fraudster altered a recovery factor.
Not whether one bound a new device.
Not whether the payment came from a takeover session.
Which is why retention has to be channel-specific.
A physical-goods record tests order, address, dispatch and delivery.
A digital-goods record tests account creation, access, download and use.
An account-takeover record tests login, session, device binding, recovery-factor changes, customer contact and linked payment history.
An authorised push-payment case tests the customer account, the claimed impersonation or communication, the payee facts, the warning history and the recall outcome.
Not glamorous.
It is what stops a generic fraud queue becoming a bucket of unrelated sadness.
Merchant non-performance is another category again.
It asks whether your merchant supplied what was promised.
It is not evidence that the customer failed to make the payment. It is not evidence that a fraudster seized the account.
The order may be real, the approval correctly made, the clearing record immaculate, and the commercial performance still disputed.
Filing that under account takeover is an efficient way to request the wrong logs before lunch.
The Loss Owner Does Not Live Inside the Approval Code
Liability follows the instrument.
The account type.
The initiator.
The notice timing.
The payment-system agreement.
The jurisdiction.
The governing rules.
Intolerably pedantic, until the first customer refund, chargeback, merchant representation and recovery attempt arrive in a different sequence.
Then it becomes a surprisingly economical way of avoiding the wrong thing in writing.
For covered U.S. consumer electronic fund transfers, Regulation E asks whether someone other than the consumer initiated the transfer without actual authority, and whether the consumer received a benefit.
A valid credential does not settle either question.
Your institution generally has 10 business days to determine whether an error occurred, and must report the result within 3 business days of completing its investigation. It may take up to 45 days only under the stated conditions, including provisional credit where required.
So your case record needs notice date, channel, account type, claimed transaction, evidence request, decision, corrective posting.
A successful login is plainly not a substitute for the statutory test.
Notice timing is not a moral fable about vigilance either.
Under Regulation E, notice within 2 business days of learning of the loss or theft of an access device limits basic exposure to the lesser of $50 or the unauthorised transfers before notice.
A different 60 calendar day statement rule applies where the transfer does not involve an access device, and can expose a consumer to later transfers only where the institution shows they would not have happened with timely notice.
Every one of those conditions matters.
Removing them is how a rule becomes folklore with a compliance department.
Credit cards take another road.
Regulation Z limits a U.S. consumer cardholder’s liability for unauthorised use to the lesser of $50 or the value obtained before the issuer is notified.
That is a cardholder-versus-issuer ceiling.
It is not a pronouncement that the issuer must permanently bear the commercial loss, nor an instruction that the merchant was fraudulent.
Your issuer can pursue a network dispute.
Your acquirer can debit the merchant under its agreement.
Your merchant can provide representation.
The allocation is contractual and evidentiary.
Less satisfying than a green tick, and generally more useful.
Authorised push-payment scams make it plainer still.
The customer may genuinely instruct the payment while acting on a fraudster’s story.
In the United Kingdom, the Payment Systems Regulator arrangements cover in-scope Faster Payments and CHAPS transfers from 7 October 2024, and not cards, cash or cheques. The stated maximum claim level is £85,000, against the Financial Ombudsman Service’s compensation limit of £455,000 for complaints referred on or after 1 April 2026.
Scope and reimbursement rules.
Not proof that the customer did not authorise the instruction, and not a promise that a completed payment can be recalled at leisure.
A Classification Is a Routing Instruction
Do not close a case as fraud confirmed unless that phrase is immediately followed by the question it answers.
Your investigator makes five separate findings.
The customer report.
The transaction facts.
The authority question.
The policy or legal regime.
The recovery.
That sequence is not ornamental.
It separates an allegation from evidence, evidence from a legal characterisation, and a reimbursement decision from recovery against a merchant or a recipient account.
The working classifications are complete enough to route the evidence: card-not-present order fraud; account takeover; authorised push-payment scam; merchant non-performance; unauthorised electronic transfer.
A synthetic-identity case takes a different route again: application trail, identity data, credit performance, linked accounts, collections findings.
Your customer service representative should not be asked to cure that with a chargeback script, however inspiring the dashboard may be.
Reconciliation should turn all of this into a dataset.
A break between approval and clearing can be timing.
Source.
Message validity.
Duplicate submission.
Stale data.
Merchant identity.
Amount.
Channel.
Manual override.
A break between clearing and fulfilment can be a missing evidence record, non-delivery, access failure, or a merchant record that is merely somewhere else.
Classify the break before you clear it.
Most firms can report how many cases reached a queue.
Far fewer can say which evidence link failed most often.
The Ladder, Since Someone Must Eventually Decide
Credential presented?
Go to the credential and authentication provider.
Account availability?
Go to the issuer.
Transaction submission?
Go to the acquirer.
Message validity?
Read the network rules.
Delivery?
Demand the merchant evidence.
Liability?
Read the applicable law and scheme rules.
Manual exception?
Demand a named case owner.
That is the whole trick.
It does not make your loss smaller.
It spares nobody an unpleasant call with a merchant, an acquirer or a customer.
It does stop the approval response impersonating every later decision.
An approval proves only the decision it records; preserve the evidence needed for every later question.
What the paper establishes
- Authentication establishes a credential or challenge result, while authorization is an issuer decision about a particular transaction at a particular time.
- A pending hold or reserve, a clearing record, a posted transaction, and final settlement are separately dated states rather than synonyms for payment completion.
- A disputed approval requires a linked record of credential, authentication result, device or channel, merchant identity, amount, authorization time, approval code, clearing record, fulfilment evidence, and dispute disposition.
- Issuer authentication and authorization records complement, but do not replace, merchant fulfilment evidence for card-not-present disputes.
- Account takeover, customer-authorised push-payment fraud, merchant non-performance, and unauthorised card use require different evidence and can produce different liability paths.
- Liability analysis belongs to the applicable product, jurisdiction, law, account contract, and scheme rulebook rather than to an approval response alone.
- A manual exception requires a named case owner and a retained record of the reason, authority, evidence, and disposition.
Questions
- Does an approved payment prove that the cardholder made the purchase?
- No. An approval records an issuer decision to allow a specified transaction at a specified time using the information then available. It does not by itself establish who used the credential, whether authentication was effective, whether the merchant supplied the goods or services, or which party bears a later loss under the applicable rulebook and law.
- What is the difference between authentication and authorization?
- Authentication establishes evidence about a presented credential or challenge result. Authorization is the issuer’s decision about whether that credential may make a particular payment to a particular merchant for a particular amount at that time. A valid authentication result can accompany a customer-authorised scam, a compromised account, or a transaction that later lacks adequate fulfilment evidence.
- What information should be kept for a disputed payment approval?
- The record keeps ten linked fields: credential, authentication result, device or channel, merchant identity, amount, authorization time, approval code, clearing record, fulfilment evidence, and dispute disposition. The fields preserve different facts. An approval code records an issuer decision, while fulfilment evidence and the dispute disposition address questions that occur after that decision.
- Is a pending payment the same thing as a posted transaction?
- No. A reserve or pending hold can make funds unavailable before a completed payment is posted, and a posted customer-ledger entry can remain subject to contractual correction or a later system rejection. Clearing, interbank settlement, customer availability, and finality are separately timed states. A case record dates each state rather than treating an app label as proof of completion.
- Why does a merchant need delivery evidence if the issuer already approved the payment?
- The issuer can assess credential status, historic spending, authentication, and cross-merchant patterns, but the merchant holds facts about the order and fulfilment. For a card-absent digital-goods dispute, Visa guidance gives successful download plus at least two specified data elements, such as IP address with device geographical location or device ID, as an example of compelling evidence.
- How is account takeover different from a customer being tricked into paying?
- Account takeover involves a person using an account without the customer’s actual authority, often after obtaining access credentials or changing recovery factors. An authorised push-payment scam involves the customer sending the payment after deception. The first case needs login, session, device, and profile-change evidence; the second needs the communication claim, payee facts, warning history, recall outcome, and applicable reimbursement analysis.
- Does a successful login make an electronic transfer authorised?
- No. For a U.S. consumer account governed by Regulation E, an electronic fund transfer is not authorised merely because it used a valid credential. The question includes whether someone other than the consumer initiated the transfer without actual authority and whether the consumer received a benefit. A successful login is evidence, not a complete legal conclusion.
- How long does a bank have to investigate an unauthorised electronic transfer?
- For covered U.S. electronic fund transfers, Regulation E generally gives the institution 10 business days to determine whether an error occurred and requires it to report the result within 3 business days after completing the investigation. An institution may take up to 45 days only under stated conditions, including provisional credit where required. Product and jurisdiction determine whether the rule applies.
- Does an unauthorised credit-card payment automatically become the merchant’s loss?
- No. In the United States, Regulation Z limits a consumer cardholder’s liability for unauthorised use to the lesser of $50 or the value obtained before the issuer receives notice. That ceiling governs the cardholder and issuer relationship. The later allocation among issuer, network, acquirer, and merchant follows the applicable contractual dispute process and the evidence presented.
- Can a customer-authorised bank transfer still qualify for scam reimbursement?
- Yes. A customer can send a payment after being deceived, which differs from a criminal initiating it with stolen credentials. In the United Kingdom, Payment Systems Regulator arrangements apply to in-scope Faster Payments and CHAPS transfers made on or after 7 October 2024, subject to their terms. Cards, cash, and cheques are outside that stated scope.
- Who decides whether an approved payment is finally payable?
- No single approval response decides that question. The issuer decides account availability and authorization; the acquirer submits the transaction; the network rulebook decides message validity and dispute procedure; the merchant establishes fulfilment; and the applicable account contract, scheme rules, law, and jurisdiction determine liability. A final decision records which authority answered each separate question.
- What should happen when someone overrides a fraud or payment decision manually?
- A manual exception receives a named case owner and a retained record of the reason, authority, evidence, time, and disposition. The record distinguishes an authorised operational decision from an unexplained system change. It also allows later review to determine whether the exception affected authentication, authorization, clearing, fulfilment, reimbursement, or recovery.