Русский
Українська
Հայերեն
ქართული
Қазақша
Español
Français
Deutsch
Italiano
فارسی
Article focus
Starting point: payment methods must not fragment an order
The customer needs choice, while the team needs one order id and one understandable result regardless of method.
When methods are separate buttons without a common backend contract, the same order gains different identifiers and status language. Support has no clear customer answer and accounting has no coherent reconciliation path.
In this case, the order keeps one internal id, while each chosen method creates a separate payment attempt. Method, provider, external id, amount, currency and state remain structured fields in one payment model.
- Do not change order contents after method selection without a new attempt.
- Store provider and method as normalized values.
- Give customers an understandable fallback after failed or expired.
- Do not consider a method confirmed before a server-side result.
Implementation: normalize statuses and allowed transitions
Provider status wording may differ, but the business needs one state set and one exception model.
Backend receives an event for the chosen method and maps it to a shared status model after validating authenticity, amount, currency and the exact payment attempt.
This layer matters for refunds, duplicate events and reporting: the business process should not depend on wording in an external dashboard. Normalization does not replace checking each provider current rules.
- Maintain a mapping of external and internal statuses.
- Keep provider raw status for investigation.
- Do not replace paid with failed from a late event.
- Route unclear operations into manual review.
After launch: reconciliation by method and provider
One dashboard should show verified operations, pending, refunds and discrepancies for every payment method.
Operations staff can see a total while filtering by payment method, provider, period, state and refund. This helps both customer support and shift closeout.
When a provider report differs from an internal ledger, the exception is tied to one specific payment attempt. The team should not correct an order manually without a reason, history and primary-source verification.
- Reconcile provider report against internal payment ledger.
- Show pending and expired separately from paid.
- Keep original method on refund.
- Define manual-correction roles and procedures.
FAQ
Does each payment method need a separate order?
No. One order can have multiple payment attempts. The payment attempt, not the order, should be a separate entity.
Can different providers use one set of statuses?
Yes, the business process needs a normalized model. Retain the original provider status for audit and investigation.
What should be checked before adding another payment method?
Current provider terms, available statuses and refunds, server-side verification, website requirements and reconciliation report format.
