BluEclipse
☰
BluEclipse platform infrastructure
The Secure Transaction System: What Happens After the Pay Button
A payment tells you that money moved. It does not tell you whose it is, whether the order arrived, or whether it is safe to release. This is the infrastructure that answers those questions — and refuses to pay out until it can.
- Category
- Fintech and transaction infrastructure
- Core technologies
- TypeScript, Node.js, Firebase, GraphQL, REST APIs, webhooks, TradeSafe and Paystack
- Built for
- Vendorah's protected transaction network
The Secure Transaction System is the infrastructure BluEclipse built to coordinate money between customers, businesses, delivery providers and the platform itself — from the moment a payment is initiated to the moment a vendor is settled.
An ordinary online payment has a pleasingly short shape. The customer pays and the merchant receives the money. There is one seller, one recipient and one moment at which the transaction is finished, which is why a payment gateway on its own is a perfectly adequate answer.
A marketplace does not get to work that way. One order may involve several independent sellers, a courier, a platform fee and a customer who has not yet received anything. The money arrives in a single movement, but it belongs to several parties, and most of them have not yet done the thing they are being paid for.
So the moment a payment succeeds, the interesting questions have not been answered — they have only just been asked:
- Was the payment actually completed?
- Which vendor does the money belong to?
- Has the order been delivered?
- Has the customer accepted the transaction?
- Is there an active dispute?
- Should the payout be delayed?
- What fees need to be deducted?
- Has this transaction already been processed?
- Does the internal record match the payment provider?
None of those are payment-gateway questions. A gateway can tell you a card was charged. It cannot tell you whether the parcel arrived, whether the buyer is satisfied, or which of four sellers is owed what. Answering them is a separate system, and that system is the subject of this article.
A transaction is a lifecycle, not an event
The central design decision is the one everything else follows from: a transaction is not the moment a payment succeeds. It is a record with a state, which moves through a sequence of controlled transitions as the order progresses.
- Payment initiated
- Payment confirmed
- In fulfilment
- In transit
- Delivered
- Accepted
- Payout eligible
- Paid out
Each transition is recorded and validated before the transaction is allowed to continue. That validation is the whole point. A state machine that accepts any transition is just a field with a string in it, and a financial record that can be set to any value by whatever spoke to it last is not a record of anything.
Different transaction types can follow different routes through that lifecycle, depending on the delivery method, the fulfilment requirements and the payment infrastructure in use. A digital product and a courier-delivered parcel do not have the same set of things that must be true before money is released, and forcing them through one identical path would mean either blocking the first or under-protecting the second.
Protected rather than immediate
Vendorah's workflows are built around delayed settlement. A successful payment is not treated as vendor revenue at the moment it clears — it is treated as funds that belong to a transaction which has not finished yet.
TradeSafe's escrow infrastructure is integrated into that process to support protected transactions between buyers and sellers, which lets funds stay protected while fulfilment happens. Around it, the transaction platform acts as the coordination layer between the marketplace, the payment infrastructure, the delivery systems and the internal accounting records — sequencing seller fulfilment, courier collection, delivery, customer acceptance, disputes, completion and fund release.
The platform is not holding the money. It is holding the question of whether the money is ready to move.
A webhook is not evidence
Payment systems lean heavily on webhooks, and webhooks are an unusually dangerous input. An HTTP request arrived at an endpoint. That is genuinely all you know about it. It is not proof that the provider sent it, that it describes the transaction it names, that it has not been delivered already, or that it is still relevant by the time it lands.
Providers retry. Networks duplicate. Events arrive out of order, or late enough that the world has moved on. Every one of those is ordinary operational reality rather than an attack, and every one of them can corrupt financial state if the handler treats the request as authoritative simply because it showed up.
The Secure Transaction System therefore validates incoming events before letting them change anything:
| Protection | What it prevents |
|---|---|
| Provider verification | Anything that can reach the endpoint being able to move money |
| Transaction identification | An event being applied to the wrong transaction |
| Duplicate event handling | A provider's retry counting as a second payment |
| State validation | A late event dragging a transaction backwards through its lifecycle |
| Idempotent processing | The same event producing a different result the second time it arrives |
| Reconciliation | An internal record quietly diverging from the provider's |
Idempotency is the one that earns its place most often. Processing the same payment event twice does not produce a harmless duplicate log line in a financial system — it produces a second settlement against the same money. Making the handler idempotent means a retry is safe by construction rather than safe by luck, which matters because retries are not an edge case. They are how payment providers are designed to behave.
The platform keeps its own books
External payment providers are not treated as the application's only source of financial truth. BluEclipse maintains its own transaction and payout records describing what happened internally, holding:
- Transaction value
- Seller allocation
- Platform commission
- Applicable fees
- Payout status
- Transaction state
- Holds
- Adjustments
- Settlement events
Keeping a parallel record is not duplication for its own sake. A provider knows what it moved; it does not know what the platform intended, which portion was commission, what was held back, or which of several sellers an amount was allocated to. Only the internal ledger holds that, and it is what makes the flow of money through the system auditable after the fact.
Having two records also makes a third thing possible: comparing them. Reconciliation logic can check internal transactions against external payment records so that inconsistencies can be identified before money is released. In a marketplace, a single incorrect state change can mean a duplicate payout or funds released prematurely — both of which are considerably easier to prevent than to recover.
Payouts are earned, not triggered
Vendor earnings are not transferred the moment a customer pays. The payout system first establishes whether the transaction has satisfied the conditions required for settlement, which may include:
- Successful payment verification
- Delivery status
- Transaction acceptance
- Dispute status
- Vendor risk state
- Required holding periods
- Previous payout activity
Transactions that qualify can then be grouped into payout batches, so scheduled vendor settlements can be processed while a complete record is kept of which transactions contributed to each one.
Tracing a payout back to its orders
That record is the part worth dwelling on, because a single vendor payout will usually contain funds originating from many separate customer transactions. The payout ledger therefore maintains the whole chain rather than only the final transfer amount:
- Customer payment
- Transaction
- Vendor balance
- Payout batch
- Settlement
Retaining the underlying allocations rather than collapsing them into a total is what makes a payout explainable. When a vendor asks what a settlement was made up of — or when anyone needs to establish that it was correct — the answer is a query, not an investigation.
Risk-aware settlement
Transaction processing is also connected to Vendorah's wider seller risk framework, so vendor behaviour can affect how settlement is handled. Depending on risk conditions, the system can apply controls such as:
- Payout delays
- Additional transaction holds
- Rolling reserves
- Payout blocking
- Manual review
- Account restrictions
The effect is a financial control layer that responds to what is actually happening in the marketplace, rather than treating every account identically regardless of history.
Delivery is a financial event
One of the more consequential architectural decisions was wiring delivery state directly into transaction state. Courier events are not treated as purely logistical information sitting in a tracking page — for supported delivery workflows they can influence whether a transaction is eligible to progress toward settlement.
- Collected
- In transit
- Delivered
- Delivery confirmed
Without that connection you get the classic failure of commerce systems built in layers that do not talk: a financial system confidently settling a transaction while the parcel it relates to is sitting in a depot. Connecting the two means the money cannot get ahead of the goods.
When a transaction does not finish normally
Not every transaction completes. When a customer raises a dispute, the transaction can be prevented from progressing toward payout while the issue is investigated — the state is held rather than allowed to run to settlement.
The distinction matters more than it might sound. Holding a transaction in place is a straightforward operation against money that has not moved. Reversing a completed payout is a recovery problem involving a third party who has already been paid and may not still have the funds. Preventing settlement during a dispute is the difference between a workflow and a negotiation.
This is particularly important where the marketplace sits between two independent parties, acting as the coordination layer rather than as one side of the deal.
Keeping the money separated
A customer may interact with several independent businesses through a single platform, which means the system has to keep clear separation between:
- Customer payments
- Vendor earnings
- Platform revenue
- Delivery costs
- Transaction fees
- Escrow activity
- Vendor payouts
Maintaining that separation is what allows a multi-vendor marketplace to operate without losing traceability between orders and financial records — which is, in the end, the only thing that makes the whole arrangement defensible.
Built beyond the checkout page
Most people will only ever see a Pay button. Behind it sits a system coordinating payment providers, marketplace records, delivery events, accounting state, security checks and eventual settlement — none of which is visible when it is working, and all of which is conspicuous when it is not.
A payment tells you that money moved. A transaction system tells you why, where it belongs, what needs to happen next, and when it is safe to release. The Secure Transaction System was built around that distinction.
Built by BluEclipse. Powering protected transactions within Vendorah.
For marketplaces and platforms
If you are holding other people's money between a payment and a delivery, the hard part is not the gateway. We have built this once and can build it again.
For technology clients
Escrow integration, webhook verification, reconciliation and automated payout scheduling — backend work where being approximately right is the same as being wrong.