- A submitted transfer and a settled payment are different business events.
- Keep the order visible while payment evidence moves through review.
- Store the proof with the commercial context needed by finance, not as an unexplained upload.
- Give operators explicit pending, accepted and rejected states plus a durable history.
- Tell the buyer exactly what happens next instead of presenting a false paid confirmation.
The client problem: checkout ends before finance can confirm the money
Card payments give ecommerce teams an immediate provider response. B2B bank transfers do not. A buyer may initiate the payment in their banking portal, send a remittance document and expect the order to progress, while the merchant may not see settled funds until later. A conventional checkout has only two tempting labels—paid or failed—and neither describes that interval honestly.
If the store marks the order paid, fulfilment may start before finance has verified the transfer. If it abandons the order, the buyer loses their basket and the account team starts rebuilding context through email. The real requirement is a third journey: preserve the commercial commitment, collect evidence, route it to the right operator and make the next decision explicit.
Model payment evidence as a journey, not a checkbox
The buyer has chosen bank transfer and receives the reference, beneficiary details and instructions needed to pay.
A file has been uploaded and attached to the correct order or engagement. The system acknowledges receipt without claiming settlement.
Finance or an authorised operator can inspect the evidence alongside amount, currency, customer and reference.
The decision advances the order or sends a clear correction request, while preserving who decided and when.
A file is not useful until it has commercial context
A generic upload field creates a storage problem disguised as a payment feature. The proof needs to be connected to the buyer, order, expected amount, currency and payment reference. The operator reviewing it needs enough context to recognise a mismatch without opening several systems.
The service should validate that a file exists, limit its size and accepted media types, and generate a safe internal record rather than trusting a browser filename. The original evidence may be retained under controlled access, but the storefront should receive only the state it needs: received, awaiting review, accepted or action required.
That record becomes the bridge between customer communication and finance operations. Support can answer whether a proof arrived. Finance can see what it relates to. The buyer does not need to resend an attachment simply because the first message reached the wrong inbox.
See the original bank-transfer proof journey
Give the buyer certainty without giving a false confirmation
The confirmation page should not borrow card-payment language. ‘Payment successful’ is inaccurate when the merchant has only received a PDF. Better copy confirms the action that really happened: the order details are saved, the proof was received, the team will review it, and the buyer will be notified of the decision.
The same state should appear in the account area and operator tools. If the buyer uploads a replacement, the system should show which proof is current rather than accumulating anonymous versions. If the evidence is rejected, the reason and next action should be concrete enough to resolve the issue without a support call.
Connect review to the bank reconciliation that follows
A proof document can justify moving an order into review, but it cannot prove that money reached the merchant’s account. The next layer is reconciliation: match bank activity to the expected customer, amount, currency and reference. Depending on the bank and finance stack, that signal may arrive through an imported statement, an open-banking feed or an ERP process.
The important design decision is to keep evidence review and settlement reconciliation as related but distinct events. Finance may accept that a document is plausible while still waiting for the bank line. Conversely, an unmistakable bank credit may settle the payment even when the buyer never uploaded a document. The order should show which signal advanced it and why.
References need tolerance without becoming fuzzy guesses. Punctuation and spacing can be normalised; amount and currency should remain exact unless the business explicitly supports fees or grouped transfers. Ambiguous matches belong in a finance queue. Automatically attaching one payment to the wrong customer is more costly than asking for one decision.
Use notifications to close every waiting loop
Asynchronous payment creates several moments where silence feels like failure. The buyer needs confirmation when evidence is received, a clear message when information is missing, and a final update when the order can progress. Operators need notification of a new case without receiving repeated alerts for the same state.
Messages should name the order and the action, but avoid attaching sensitive documents to broad email threads. A secure account route can expose the current state and any correction request. Internal notifications should deep-link to the review screen with the same commercial context visible there.
Service expectations also belong in the product. If review normally happens within one business day, say so. Age the queue and escalate cases that exceed that promise. The payment method becomes trustworthy when customers can predict the next step and the operations team can see which promise is about to be missed.
The operator interface is part of the payment capability
A backend endpoint alone does not make bank transfer operational. The team needs a queue ordered by age and commercial priority, a preview or download path, customer and order context, and guarded actions for acceptance or rejection. Filters should distinguish new evidence from cases already waiting on the buyer.
Every action should produce a durable event. That history protects both sides when a question appears later: when was the proof received, which document was reviewed, who accepted it, and when did the order become eligible for the next step? The goal is not bureaucracy. It is to prevent an asynchronous payment method from becoming an invisible manual exception.
Why this belongs inside the commerce system
Bank transfers are often pushed into email because the ecommerce platform assumes synchronous payment. That separates payment evidence from the order it is meant to unlock. A composable commerce foundation lets the merchant add a domain-specific payment journey while keeping customers, orders, states and operator actions connected.
The architecture choice is valuable because the business rule can be represented directly: evidence received is not funds settled, but it is meaningful progress. Once that distinction exists in the platform, notifications, fulfilment gates, support views and reporting can all respond to the same state instead of guessing from inboxes.
Common questions
No. It should mark the evidence as received. Payment acceptance or settlement needs its own authorised decision or reconciliation event.
Email can carry the file, but it does not reliably connect evidence, order state, reviewer decision and buyer communication. The commerce system should own that relationship.
Yes. Treat each upload as identifiable evidence and make the active proof explicit so a corrected document does not erase the history of the earlier submission.