All projectsCase study — Software engineer

Cross-border e-commerce payments

Owned the payment gateway for a cross-border e-commerce platform: front-to-back integration and the data flow behind it, with local payment providers per country and €100K–1M+ a month in volume.

RoleSoftware engineer
Period2022.04 — 2023.09
Monthly volume€100K–1M+
Providers5
Settlement60% faster
CHECKOUTweb · mobilePAYMENT GATEWAYrouting · idempotencyone event shapeLOCAL PSPcardsLOCAL PSPbank transferLOCAL PSPwallet+ 2 MORE · 5 PROVIDERSLEDGERorders · settlementCHECKOUT → PSP → LEDGER

The problem

Selling into several countries means paying the way each country pays. Five local payment providers, five webhook dialects, five bank settlement file formats — and one ledger that had to agree with all of them at the end of every day.

What I owned

The payment gateway itself: the checkout front end, the backend integration with each provider, and the data flow between them — from the moment a customer picks a payment method to the moment the order, the payment record and the ledger entry all agree.

Routing

Each transaction picks a provider by country, payment method and cost. The routing rules live in data so operations can change them without a deploy, and every decision is recorded on the transaction for later reconciliation.

Settlement

The CODA integration replaced a manual matching step: bank statements are parsed, matched against the ledger by reference and amount, and only genuine exceptions reach a human. That is where the ~60% time saving came from — not from faster code, from less work.

Reliability safeguards

The gateway uses idempotency keys, one normalized webhook event shape, and durable raw provider payloads. Together they make retries safe, keep downstream processing uniform, and preserve the evidence needed to investigate a disputed transaction.

問題

要賣到好幾個國家,就得用每個國家習慣的方式收錢。五家各國本地金流商、五種 Webhook 方言、五種銀行清算檔案格式——而每天結束時,帳本得跟它們全部對得起來。

我負責的部分

公司電商的 Payment Gateway:結帳前端、每一家金流商的後端串接,以及兩者之間的資料流——從客人選擇付款方式,到訂單、付款紀錄與帳本三者一致為止。

金流路由

每筆交易依國家、付款方式與成本挑選金流商。路由規則放在資料裡,營運可以自己調整不用重新部署,而且每次的判斷結果都記在交易上,事後對帳查得到。

清算對帳

導入 CODA 之後,原本人工比對的步驟被取代:解析銀行對帳單,用參考號與金額跟帳本比對,只有真正的例外才需要人看。約 60% 的時間節省來自這裡——不是程式跑得比較快,是要做的事變少了。

可靠性設計

系統使用冪等鍵、統一的 Webhook 事件格式,並完整保留金流商原始 payload。這讓 retry 不會重複入帳、下游處理只需認一種格式,也留下處理交易爭議所需的完整證據。