How Money Actually Moves: Why Every Software Engineer Should Understand This

“I tapped Send. The API returned 200 OK. The payment was successful... right?”

Not necessarily.

One of the biggest misconceptions in software engineering is believing that a successful API response means money has moved. It doesn’t.

Behind every successful payment lies a carefully orchestrated sequence of authentication, authorization, ledger updates, notifications, settlement, and reconciliation. What appears to users as a simple tap on a screen is, in reality, a distributed system where every step must be correct, secure, and recoverable.

This is where finance meets software engineering.

A simple payment

Imagine this. Kwame wants to send GHS 100 from his MTN Mobile Money wallet to Ama’s Vodafone Cash wallet. For Kwame, it’s effortless.

1. Open the app.
2. Enter Ama’s number.
3. Enter GHS 100.
4. Confirm with his PIN.
5. Done.

The entire interaction takes less than a minute. But underneath that simple experience, dozens of events occur before a single cedi changes hands.

1. The user initiates the payment

Kwame enters the recipient’s phone number, the amount, and his PIN.

2. Authentication

Before anything else, the platform answers one question: Is this really Kwame?

The system verifies things such as:

• Is the PIN correct?
• Is the SIM active?
• Is the wallet active?
• Has the account been blocked?
• Has suspicious activity been detected?

Only after successfully verifying the customer’s identity does the payment continue.

3. Authorization

Now comes a different question: Should this payment be allowed?

Notice the distinction.

Typical checks include whether Kwame has sufficient balance, whether he’s exceeded his daily limit, whether Ama’s wallet is valid, and whether any fraud rules are triggered.

4. Recording the transaction

Before updating any balances, the platform creates a transaction record.

Why create this record before moving money? Because distributed systems fail. Servers crash. Networks disconnect. Databases restart.

5. Updating the ledger

This is the moment where value actually changes. Contrary to popular belief, payment systems don’t simply subtract money from one balance and add it to another. They update a ledger using double-entry accounting.

Every debit has a corresponding credit. Money doesn’t disappear. Money doesn’t magically appear. It simply moves from one account to another.

6. Customer notifications

Only after the ledger has been updated do customers typically receive notifications.

• Kwame receives “Payment Successful”
• Ama receives “You have received GHS 100”

7. Settlement

Now suppose Kwame uses MTN Mobile Money while Ama uses Vodafone Cash. The payment may already appear complete to both customers — but behind the scenes, another process begins.

The two institutions must eventually settle their obligations through the national payment infrastructure. Depending on the payment scheme, settlement may happen immediately, in batches, or at scheduled intervals.

What this means for software engineers

Imagine your frontend immediately displays “Payment Successful.” A few seconds later, the backend discovers that settlement failed.

Now what? Should the customer be refunded? Should the payment be reversed? Should the merchant still deliver the product? Should operations investigate?

Thinking like an architect

Many frontend engineers naturally think: “Did the API return 200 OK?”

Payment engineers think differently. They ask:

• Did the ledger commit successfully?
• Is this transaction idempotent?
• Can this request be safely retried?
• What happens if the customer taps Pay twice?
• What if the notification service is unavailable?
• Can tomorrow’s reconciliation prove this transaction occurred?
• Can the system recover from failure without losing money?

These aren’t edge cases. They’re everyday design considerations when building financial systems. This is the difference between building user interfaces and designing financial infrastructure.

Money should only move when the ledger says it moved — not when the UI says it moved.

Everything else — buttons, animations, loading indicators, receipts, notifications, emails, and success screens — is built around that single source of truth. The ledger decides reality. The user interface merely reflects it.

Final thoughts

Every time someone taps Send, they see a simple interaction. What they don’t see is the authentication, authorization, ledger updates, settlement workflows, fraud checks, audit logs, retries, reconciliation, and distributed systems working together to ensure every cedi is accounted for.

That’s the beauty of financial software. When it’s designed well, complexity becomes invisible. And perhaps that’s the greatest compliment a payment system can receive.