Aily Kang
한국어

Menu

← All case studies
2016~Professional work

Commerce settlement and tax-invoice integration (legacy PHP)

PHPMySQL바로빌 API은행 자동확인 APIYoungcart / Gnuboard

EvidenceTax-invoice issue / cancel / balance API integration

Context

For years I maintained commerce systems where members check their own earnings and points, and where tax invoices have to be issued to businesses automatically.

Problem

A wrong screen produces a complaint. Wrong settlement produces a financial problem. The two have completely different tolerances for error.

Decisions

Kept money logic out of presentation logic

Point accrual, deduction and settlement calculation don't live in the same layer as display code. Screens get change requests constantly; settlement logic should require justification to change.

Took tax invoicing out of human hands

Issue, pre-issue, cancel and balance-check were integrated through the Barobill API. Manual issuance always starts dropping records once volume rises.

Stopped operators from reconciling deposits by eye

An automated bank-deposit API removed the job of sitting with a bank statement matching payments against orders by hand.

What I owned

  • Backend development
  • Third-party API integration
  • Settlement logic
  • Legacy maintenance

Actual deliverables

  • Tax-invoice issue / cancel / balance API integration
  • Automated bank deposit reconciliation
  • Member back-office with points and settlement logic

Scope and verification

Tax-invoice issue / cancel / balance API integration

It's an old PHP stack and I'd structure it differently today. But having handled tax invoicing, deposit reconciliation and point settlement in a live production environment is experience that outlives the stack.

If you need this kind of work

Describe the thing you're currently stuck on. I'll reply by first separating what I can take on from what I can't.

kjyhopekr@gmail.com

More in this field