Make a payment. Then try to break it.

Pay at the checkout below and watch what the platform does with it. Then put it under pressure: charge twice, pay with a method that was switched off, alter the books, forge a notification.

This is a simulation. It runs in your browser on made-up data: no money moves, and nothing you do here is sent to us.

What the customer sees

Nile Stores Secure checkout

Amount due

SDG 1,250.00

Order 1042

Reference

Confirmed with

Blink Pay · secure checkout

What the platform does

Payment WaitingProcessingSucceeded Tests held0/4

Nothing has happened yet. Press Pay now and each station fills in as the payment reaches it. Each one then has a test.

A double tap, a retry, a dropped connection: the same request can arrive more than once. The platform knows it by its id, and answers again without charging again.
What the checkout sentPOST /v1/public/checkout/{token}/pay

Stored under

Fingerprint of the request

Answer

Times the request arrived
1

Charges to the customer
1
Try to charge twice

Send the request again exactly as it was, or reuse its id for something different.

Held. The platform knew the request by its id and fingerprint. It returned the first answer again, and the customer was charged once.

Refused. The id had already been used for a different request, so nothing was created and nothing was charged.

The method the customer picks decides which provider takes the payment. Both are rows of configuration, so offering a method or switching it off is a setting, not a release.

Method	Provider	Connects by	Offered
	WALLET	Blink's own ledger
	DEMO_BANK	Direct API, one-time code
	DEMO_CARDS	Redirect to the processor

Switch a method off, then pay with it anyway

Switch a method off above and the checkout stops offering it. Then act as a customer whose page was already open.

Refused. The platform checked the method against the merchant's settings when the payment arrived, and turned it away. Nothing was created.

Both sides of the movement are written together or not at all. The transaction then carries a seal worked out from its contents and from the seal before it, and a check that runs on a schedule works every seal out again.

Ledger transactionTRANSFER · COMMITTED

Account	Debit	Credit
Customer's wallet wallet:wal_demo_customer
Merchant's wallet wallet:wal_nile_stores

Debits less credits0.00

Transaction
Seal
Seal before it
What is sealed

Seal worked out again: it matchesSeal worked out again: it no longer matches.

Try to change the books

Write half a movement, or alter one that is already written.

Refused. Debits and credits did not come to zero, so nothing was written. Not even the half that was offered.

Caught. The check worked the seal out again and it no longer matched, and the wallet's balance no longer agreed with its ledger. The wallet is held for review before any more money can move.

This payment moved on the provider's books, not on Blink's ledger. The platform keeps the record and checks it against what the provider reports.

Provider
Payment reference
Status: SUCCEEDED

The ledger test needs a wallet payment

Pay with Blink Wallet and this station shows the entries and their seal, with two ways to attack them.

The fee is worked out the moment the payment succeeds, so the merchant sees what landed and why. Their system is then told with a signed notification, so it can tell a real one from a forgery.

Payment

Fee, 1.5%

Net to the merchant

Settlement
In the merchant's next settlement run, on their schedule.
Notification to the merchant's systemPAYMENT.SUCCEEDED

X-PayRail-Signature

Shared secret, for this demo
demo-secret-not-a-real-one

Signature worked out again: it matchesSignature worked out again: it no longer matches.
Try to forge the notification

Change the amount while the notification is on its way to the merchant's system.

Caught. The signature was made from the notification as it left. With the amount changed it no longer matches, so the merchant's system knows to discard it.

Four attempts, four held. The real platform is shown in person, in the bank and merchant portals. Book a demo

What happened, in order0

What the four tests show.

Each one is a promise a payments platform has to keep when it is somebody else's money.

A customer is charged once.
Every payment request carries an id. Send the same request twice and the platform answers twice but charges once. Reuse the id for something different and it is refused.
Offering a method is a setting.
Which methods a merchant offers, and which provider takes each one, are rows of configuration. Change a row and the next customer sees it. A payment that arrives for a switched-off method is turned away before anything is created.
The books cannot be changed quietly.
A movement is written with both sides or not at all. Each transaction is sealed to the one before it, and a check that runs on a schedule works the seals out again. A wallet that fails is held for review.
A notification can be trusted.
What the platform sends to a merchant's system is signed with a secret the two share. Change one figure on the way and the signature no longer matches. If the merchant's system is down, the notification is kept and tried again.

The rules above are the platform's own. The merchant, the customer, the providers and the figures on this page are made up, and the fingerprint, seal and signature are worked out in your browser with SHA-256.

Now see the real one.

A walkthrough of the bank and merchant portals, on your own use case.

Book a demo Back to Blink Pay

Make a payment. Then try to break it.

What the four tests show.

A customer is charged once.

Offering a method is a setting.

The books cannot be changed quietly.

A notification can be trusted.

Now see the real one.