Khi lần đầu tiếp cận bài toán multiple payment method, tôi từng nghĩ đây chủ yếu là một bài toán chia số tiền.

Ví dụ: một dịch vụ có giá 700 USD. Khách hàng có gift card trị giá 100 USD và muốn thanh toán 600 USD còn lại bằng credit card.

Về mặt số học, bài toán khá đơn giản:

700 USD = 100 USD Gift Card + 600 USD Credit Card

Nhưng khi bắt đầu triển khai trên môi trường thực tế, đặc biệt trong một hệ thống có POS device, Credit card, Cash, Internal wallet và Gift card, tôi nhận ra phần chia tiền chỉ là một phần rất nhỏ.

Những câu hỏi khó hơn bắt đầu xuất hiện:

Payment method nào nên được xử lý trước?
Nếu một phương thức thành công nhưng phương thức tiếp theo thất bại thì sao?
Database rollback có hoàn lại được giao dịch đã tạo ở third party không?
Nếu request đến third party bị timeout, làm sao biết khách đã bị charge hay chưa?
Nếu khách muốn thay đổi sản phẩm hoặc giá trong lúc POS đang chờ quét thẻ thì sao?
Nếu refund thành công ở third party nhưng backend không nhận được response thì xử lý thế nào?

Từ đó, tôi nhận ra multiple payment method không đơn thuần là bài toán cộng trừ số tiền.

Nó là bài toán điều phối nhiều payment workflow khác nhau, trong khi vẫn phải bảo đảm dữ liệu nhất quán và khách hàng không bị mất tiền.

Một số trường hợp thực tế

Multiple payment method có thể xuất hiện trong rất nhiều tình huống quen thuộc.

Trường hợp 1: Chia một hóa đơn bằng nhiều phương thức

Hai người dùng chung một hóa đơn nhưng muốn thanh toán riêng.

Người A dùng credit card.
Người C dùng tiền mặt.

Hệ thống phải ghi nhận cả hai khoản thanh toán vào cùng một order hoặc invoice, đồng thời bảo đảm tổng số tiền bằng đúng giá trị cần thanh toán.

Trường hợp 2: Gift card kết hợp credit card

Một dịch vụ có giá 700 USD.

Khách hàng có gift card trị giá 100 USD và muốn thanh toán phần còn lại bằng credit card.

Gift Card:     100 USD
Credit Card:   600 USD
Total:         700 USD

Trong trường hợp này, nếu credit card bị từ chối sau khi gift card đã bị trừ, hệ thống phải trả lại gift card cho khách hàng.

Trường hợp 3: Cash kết hợp credit card

Một sản phẩm có giá 2.000 USD.

Khách hàng có 1.500 USD tiền mặt và hạn mức 3.000 USD trong credit card. Tuy nhiên, khách muốn giữ lại một phần hạn mức thẻ để sử dụng cho mục đích khác.

Khách có thể chọn:

Cash:          1.000 USD
Credit Card:   1.000 USD
Total:         2.000 USD

Ở đây, hệ thống không chỉ cần chia số tiền mà còn phải ghi nhận đúng ai đã nhận cash, thời điểm nào và điều gì xảy ra nếu phần credit card thất bại.

Trường hợp 4: Kết hợp nhiều payment method trong một flow

Một payment có thể bao gồm đồng thời:

POS card
Credit card
Cash
Internal wallet
Gift card.

Đây là lúc bài toán bắt đầu trở nên phức tạp.

Một phương thức có thể xử lý hoàn toàn trong hệ thống nội bộ. Một phương thức cần gọi đến third party. Một phương thức lại cần nhân viên xác nhận thủ công.

Không thể coi tất cả payment method là những bước giống nhau.

Bài toán thật sự là payment orchestration

Nếu chỉ nhìn vào tổng tiền, multiple payment method có vẻ là một phép chia đơn giản.

Nhưng hệ thống thực tế phải quản lý một payment plan gồm nhiều payment component.

Ví dụ:

Payment Plan
├── POS Card:          500 USD
├── Saved Card:        300 USD
├── Gift Card:         100 USD
├── Internal Wallet:    50 USD
└── Cash:               50 USD

Tổng các component phải bằng đúng số tiền của order.

Tuy nhiên, việc validate tổng tiền mới chỉ là bước đầu.

Hệ thống còn phải trả lời:

Component nào đang chờ?
Component nào đã được xử lý?
Component nào đã thất bại?
Component nào cần refund?
Component nào chưa xác định được trạng thái?
Toàn bộ payment plan đã hoàn thành hay chưa?

Vì vậy, một thiết kế tốt nên xem payment plan là một workflow có state machine, không phải chỉ là một danh sách các transaction được tạo nối tiếp nhau.

Gom nhóm payment method

Một trong những kinh nghiệm quan trọng tôi rút ra là nên gom các payment method theo đặc tính xử lý thay vì chỉ theo tên.

Nhóm 1: Internal payment

Nhóm này gồm:

internal wallet;
gift card;
store credit;
loyalty balance.

Đây là những phương thức hệ thống thường kiểm soát hoàn toàn.

Ta có thể thiết kế chúng theo mô hình:

AVAILABLE => RESERVED => CONSUMED

Nếu payment flow thất bại trước khi hoàn tất:

RESERVED => RELEASED

Reservation tốt hơn việc trừ tiền ngay rồi cộng lại, bởi vì nó giảm số lượng transaction đảo ngược và giúp lịch sử tài chính rõ ràng hơn.

Nhóm 2: External electronic payment

Nhóm này có thể gồm:

Credit card.
POS card.
Các hình thức thanh toán điện tử thông qua third party.

Điểm quan trọng: hệ thống nội bộ không kiểm soát hoàn toàn vòng đời giao dịch.

Một request đến third party có thể:

Thành công.
Thất bại.
Timeout.
Được xử lý thành công nhưng response không quay về.
Được gửi webhook nhiều lần.
Hoặc trả kết quả muộn.

Do đó, timeout không đồng nghĩa với payment failed. Trong một số trường hợp, trạng thái chính xác phải là: UNKNOWN Khi đó hệ thống cần query lại third party hoặc chờ reconciliation thay vì charge lại ngay.

Nhóm 3: Physical payment

Cash là ví dụ rõ nhất do không thể được refund bằng API.

Nếu nhân viên đã nhận tiền nhưng các phần thanh toán khác thất bại, hệ thống phải tạo một nhiệm vụ nghiệp vụ:

CASH_RETURN_REQUIRED

Sau khi nhân viên thực sự trả lại tiền cho khách, trạng thái mới được chuyển thành:

CASH_RETURNED

Việc tự động đánh dấu cash là refunded ngay khi backend gặp exception có thể khiến dữ liệu không phản ánh đúng thực tế.

Độ ưu tiên xử lý payment

Không có một thứ tự duy nhất phù hợp với mọi hệ thống.

Thứ tự xử lý nên dựa trên một số yếu tố:

Payment method có hỗ trợ reserve hay không
Có hỗ trợ authorize trước và capture sau hay không
Chi phí refund
Khả năng rollback
Xác suất thất bại
Trải nghiệm người dùng
Quy trình vận hành tại quầy
Chính sách kinh doanh

Một nguyên tắc hữu ích là:

Reserve sớm, commit muộn.

Ví dụ:

1. Validate toàn bộ payment plan
2. Reserve internal wallet
3. Reserve gift card
4. Authorize saved card
5. Process hoặc authorize POS card
6. Xác nhận cash
7. Capture external payments
8. Commit internal balances
9. Complete order

Cách này giúp giảm nhu cầu refund.

Nếu một credit card không thể authorize, hệ thống có thể release wallet và gift card reservation mà không cần tạo transaction hoàn tiền.

Tuy nhiên, thực tế không phải payment method nào cũng hỗ trợ tách riêng authorize và capture.

POS flow cũng có thể bắt buộc phải xử lý sớm vì cần khách hàng tương tác trực tiếp với thiết bị.

Do đó, thay vì cố tìm một thứ tự cố định, hệ thống nên định nghĩa lifecycle riêng cho từng payment method:

Validate => Reserve hoặc Authorize => Commit hoặc Capture => Compensate nếu cần

Flow charge tôi từng triển khai

Trong một hệ thống thực tế, flow có thể diễn ra như sau:

1. Tạo POS payment và gửi đến POS device
2. Khách hàng quét hoặc chạm thẻ
3. Backend nhận webhook success từ third party
4. Tạo và lưu POS transaction
5. Xử lý saved credit card
6. Xử lý cash, wallet, gift card và các payment còn lại
7. Thực hiện các action sau thanh toán

Ở phía client, hệ thống hiển thị loading view hoặc trạng thái chờ sau những bước quan trọng:

Đang kết nối đến thiết bị thanh toán

Vui lòng quét hoặc chạm thẻ

Đang xác nhận giao dịch

Client không nên tự kết luận payment thành công chỉ dựa vào màn hình của POS device.

Trạng thái cuối cùng phải đến từ backend, sau khi backend đã nhận và xử lý kết quả từ third party.

Client có thể cập nhật trạng thái bằng:

Polling
WebSocket
Server-Sent Events
Push notification
Một status page

Điểm cần lưu ý là webhook xảy ra bất đồng bộ.

Request ban đầu từ client có thể đã kết thúc từ lâu. Vì vậy, không thể dựa hoàn toàn vào việc throw exception sang client.

Exception nên được chuyển thành domain state có thể truy vấn.

Ví dụ:

{
  "paymentId": "payment_123",
  "status": "COMPENSATING",
  "failedStep": "SAVED_CARD",
  "errorCode": "CARD_DECLINED",
  "message": "Một phần thanh toán thất bại. Hệ thống đang hoàn lại khoản đã thu trước đó."
}

Không nên giữ một database transaction quá dài

Trong phiên bản đầu, tôi từng xem các bước sau webhook như một flow cần được bọc trong một database transaction lớn.
Tư duy này có điểm hợp lý: nếu bất kỳ bước nào thất bại, toàn bộ dữ liệu nội bộ phải rollback.
Tuy nhiên, vấn đề xuất hiện khi database transaction bao phủ cả những lần gọi đến third party.

Ví dụ:

BEGIN TRANSACTION

Save POS transaction
Call third party for saved card
Update wallet
Update gift card
Update order

COMMIT

Một API call đến third party có thể mất nhiều giây hoặc timeout.

Trong thời gian đó, database transaction vẫn giữ connection và lock.

Điều này có thể gây:

Transaction kéo dài
Deadlock
Giảm throughput
Các request khác bị block
Khó retry
Khó xác định trạng thái thật của external payment

Một thiết kế tốt hơn là dùng nhiều local transaction ngắn.

Transaction 1
- ghi nhận POS success;
- cập nhật payment attempt;
- tạo nhiệm vụ xử lý bước tiếp theo;
- commit.

External processing
- gọi third party;
- nhận kết quả.

Transaction 2
- ghi nhận kết quả;
- cập nhật trạng thái;
- commit.

Database transaction vẫn rất quan trọng, nhưng chỉ nên bảo vệ dữ liệu nội bộ.

Nó không thể làm cho các hệ thống khác trở thành một phần của ACID transaction.

Database rollback không phải payment rollback

Đây là bài học quan trọng nhất.
Giả sử POS payment đã thành công ở third party, sau đó saved credit card bị từ chối.
Database có thể rollback các thay đổi nội bộ.
Nhưng database rollback không thể khiến giao dịch POS tự động biến mất.

Lúc này cần một compensation workflow:

Payment component failed
↓
Mark payment plan as COMPENSATION_REQUIRED
↓
Refund POS payment
↓
Release wallet reservation
↓
Restore gift card reservation
↓
Handle cash return if needed
↓
Mark payment plan as COMPENSATED

Vì vậy, một payment workflow thực tế thường là:

Local transaction + External side effects + Compensation

Đây gần với Saga orchestration hơn là một database transaction truyền thống.

Vì sao refund trực tiếp trong catch chưa đủ an toàn?

Một implementation phổ biến có thể giống như sau:

try {
    beginTransaction()

    savePosTransaction()
    chargeSavedCard()
    updateWallet()
    updateGiftCard()
    updateOrder()

    commit()
} catch (error) {
    rollback()

    refundPos()
    refundSavedCard()

    throw error
}

Cách này có thể chạy tốt trong các trường hợp đơn giản, nhưng vẫn tồn tại nhiều failure window.

Process chết sau rollback nhưng trước refund

Database đã rollback nhưng refund chưa được gọi.
Khách hàng vẫn bị charge, trong khi hệ thống có thể không còn đủ record để biết khoản nào cần hoàn.

Refund thành công nhưng response bị mất

Third party đã refund thành công nhưng backend bị timeout.
Nếu hệ thống retry mà không có idempotency hoặc không kiểm tra trạng thái, workflow có thể trở nên khó kiểm soát.

Chỉ một phần compensation thành công

POS refund thành công nhưng saved card refund thất bại.
Một trạng thái chung như FAILED không đủ để mô tả trường hợp này.

Vì vậy, refund nên được lưu thành các compensation step độc lập:

POS_REFUND_REQUIRED
SAVED_CARD_REFUND_REQUIRED
WALLET_RELEASE_REQUIRED
GIFT_CARD_RELEASE_REQUIRED
CASH_RETURN_REQUIRED

Mỗi step cần có:

Trạng thái riêng
Idempotency key
Retry
Audit log
Thời điểm thực hiện
Provider reference
Lý do thất bại
Cơ chế manual review

Một worker có thể xử lý compensation bất đồng bộ và retry khi cần thiết.

Không nên xóa dấu vết payment đã xảy ra

Một lỗi thiết kế khác là rollback luôn transaction record của một external payment đã thành công.
Nếu POS payment đã thật sự xảy ra ở third party, local database nên giữ lại sự kiện đó.

Thay vì xóa record, ta cập nhật vòng đời:

POS CHARGE: SUCCEEDED
↓
REFUND REQUIRED
↓
REFUND PROCESSING
↓
REFUNDED

Trong payment hoặc accounting ledger, nên lưu các movement riêng:

CHARGE:   +500 USD
REFUND:   -500 USD
NET:         0 USD

Không nên chỉnh sửa charge record như thể giao dịch chưa từng xảy ra.

Cách làm này tốt hơn cho:

Audit
Reconciliation
Báo cáo
Dispute
Partial refund
Theo dõi phí
Điều tra sự cố

Cho phép cancel trước khi khách charge

Trước khi khách đưa thẻ vào POS, payment flow có thể được cancel tương đối an toàn.

Khách hàng có thể muốn:

Thay đổi sản phẩm
Thay đổi số lượng
Cập nhật giá
Đổi payment method
Thay đổi số tiền phân bổ
Hủy giao dịch

Flow có thể là:

PAYMENT_CREATED => WAITING_FOR_CARD => CANCELLED

Sau đó hệ thống tạo payment attempt mới.
Không nên sửa trực tiếp payment plan cũ trong khi POS device có thể vẫn đang hiển thị số tiền trước đó.

Tốt hơn là:

Cancel old attempt => Create a new attempt => Send the new amount to POS

Điều này giúp tránh trường hợp POS đang charge giá cũ trong khi order đã được cập nhật sang giá mới.
Sau khi khách đã đưa thẻ vào thiết bị, tình hình phức tạp hơn.
Payment có thể đang processing.
Khi đó, yêu cầu cancel không đồng nghĩa với việc payment chắc chắn đã dừng.

Hệ thống cần chờ trạng thái cuối cùng:

CARD_PRESENTED => PROCESSING => SUCCEEDED hoặc FAILED

Nếu payment đã authorize nhưng chưa capture, có thể void.
Nếu đã capture, có thể cần refund.
Nếu chưa xác định được kết quả, hệ thống phải reconciliation trước khi hành động tiếp.

Một số lưu ý quan trọng

Idempotency

Idempotency cần xuất hiện ở nhiều lớp:

Client gọi backend
Backend gọi third party
Webhook handler
Refund hoặc compensation worker

Một request bị retry không được tạo thêm charge ngoài ý muốn.

Duplicate và out-of-order webhook

Webhook có thể được gửi nhiều lần hoặc đến không đúng thứ tự.

Webhook handler phải:

Verify signature
Lưu event ID
Xử lý idempotent
Kiểm tra state transition hợp lệ
Không giả định event chỉ đến một lần

Concurrency control

Cần chống các trường hợp:

Hai webhook cùng xử lý
Client cancel đúng lúc webhook success đến
Hai worker cùng xử lý một component
Order bị sửa trong lúc payment đang chạy

Có thể sử dụng:

Optimistic locking
Version number
Short row-level lock
Unique constraint
Compare-and-set state

Outbox pattern

Nếu database đã commit nhưng process chết trước khi publish background job, workflow có thể bị kẹt.

Outbox pattern giúp bảo đảm trạng thái và nhiệm vụ tiếp theo được ghi trong cùng local transaction.

Reconciliation

Không nên phụ thuộc hoàn toàn vào webhook.

Cần có job định kỳ để so sánh:

Third-party transaction <=> Local payment ledger

Nếu có chênh lệch, hệ thống tạo cảnh báo hoặc repair task.

Phân biệt critical và non-critical action

Không phải action nào sau payment cũng nên khiến payment thất bại.

Critical action có thể gồm:

Đánh dấu order đã thanh toán;
Commit inventory;
Cấp quyền sử dụng dịch vụ.

Non-critical action có thể gồm:

Gửi email
Analytics
Notification
Cập nhật CRM

Một email gửi thất bại không nên khiến toàn bộ payment bị refund.

Kết luận

Multiple payment method chưa bao giờ chỉ là bài toán chia tiền.
Phần khó nhất nằm ở việc điều phối nhiều payment method có đặc tính hoàn toàn khác nhau.
Internal wallet có thể reserve và release.
Gift card có thể giữ số dư tạm thời.
Credit card cần làm việc với third party.
POS cần tương tác trực tiếp với khách hàng và xử lý bất đồng bộ.
Cash lại phụ thuộc vào xác nhận thủ công của nhân viên.

Một thiết kế production-grade nên kết hợp:

Payment plan
State machine
Short local transaction
Reservation và authorization
Idempotency
Durable compensation
Immutable ledger
Retry
Reconciliation
Audit log
Client status tracking

Điều quan trọng nhất tôi học được là:

Database rollback không đồng nghĩa với payment rollback.

Một khi tiền đã đi qua third party hoặc được nhân viên nhận trực tiếp, việc hoàn tác không còn là một câu lệnh rollback.
Nó trở thành một nghiệp vụ độc lập, có trạng thái, có thể thất bại, cần retry và phải được theo dõi cho đến khi hoàn tất.
Nếu chỉ nhìn multiple payment method như một phép chia số tiền, ta có thể tạo ra một flow chạy được trong happy path.
Nhưng nếu nhìn nó như một distributed payment workflow, ta mới có thể xây dựng một hệ thống đủ an toàn để vận hành trong thực tế.

Góc Kỹ Thuật Thực Chiến

Multiple payment method: điều khó nhất không phải chia tiền, mà là rollback