THE PLATFORM
Everything a payment provider needs to operate
ONLA builds the software a payment provider runs on: merchant onboarding and underwriting, multi-acquirer routing, risk screening that happens before authorization, compliance case handling, a double-entry ledger, settlement, and the acceptance channels merchants actually integrate with. Forty-two modules and over 66,000 lines of production Go, built as one system, not assembled from separate products.
This is a platform for operating as a payment provider, not only for accepting a card. What follows describes what the software does, function by function, at the level of detail an evaluator asks about in a second meeting.
LAYER 01 · ONBOARDING
From application to first transaction
Onboarding is where platforms quietly fail. Underwriting here is a set of persisted states, not a form that is either finished or lost. An application can be submitted in part, returned for correction, and resumed exactly where it was left.
Staged verification
The verification wizard collects company details, registration, and identification. Each stage persists independently. An application can be paused, returned for correction, and resumed from the stage that failed. The applicant does not start again from the top.
Beneficial owners
Owners are held in a registry of their own, not as free text on a form. The required document set is derived from the business type. Documents carry their own review state, so one rejected certificate does not invalidate an otherwise complete and verified file.
Status lifecycle
Merchants move through explicit pending, active, suspended, and terminated states. Configuration travels with the record, not in an operator's manual notes. Settlement cycle, timezone and payout destination for each currency are bound to the merchant profile and read from it.
Separated keys
Each merchant holds a secret API key for server-side calls and a publishable key for client interfaces. These are issued, rotated, and revoked independently. Merchant users authenticate separately from API clients. Rotating a machine key does not lock out staff.
Versioned pricing
Rates are configured per merchant and card category, with percentage and fixed components. Every change is versioned with its history. The rate that applied to a transaction last quarter can be shown, not inferred.
Introducer books
Dealers and agents are modeled as a hierarchy carrying specific commission terms. A dealer sees only their portfolio. Commission is calculated from the records that produce merchant settlement. There is no second spreadsheet to reconcile.
LAYER 02 · PROCESSING
Multi-acquirer processing with inspectable routing
Multi-acquirer processing requires the platform to explicitly state which rule selected which acquirer for a specific transaction. It has to evaluate conditions as they change and pull a failing provider out of rotation before an operator notices.
Full authorization lifecycle
Authorization, capture, void, and refund operations take an idempotency key. Capture and refund support partial amounts against the remaining balance. State changes leave through a transactional outbox. A retried request or a dropped connection cannot move money twice.
Provider circuit breakers
Every provider implements a common interface and is wrapped in a breaker that tracks failures. The breaker opens before a degraded acquirer absorbs live traffic and drops it from selection. Merchants are not the ones who report the provider outage.
3DS exemption engine
Both protocol versions are supported. Low-value and transaction-risk-analysis exemptions are evaluated on each transaction against configurable per-merchant thresholds and per-currency limits. A soft decline from the issuer is stepped up to a challenge, not returned as a hard failure.
LAYER 03 · RISK
Scored before authorization
A risk decision that arrives after the money moved is a report, not a control. Screening, monitoring, and scoring run in front of the acquirer. The pipeline fails closed, refusing the transaction outright if any check cannot complete its evaluation.
The score is a weighted composition, not a single test. No individual signal decides on its own.
Fail-closed pipeline
Before reaching an acquirer, transactions pass sanctions, anti-money-laundering, and fraud gates in sequence. The pipeline fails closed. If a gate errors instead of returning a verdict, the transaction is refused. A check that could not run is a check that did not pass.
Velocity in four dimensions
Attempt counts and amounts are tracked over rolling windows by card, IP address, customer, and merchant. Limits are set per merchant. Card testing shows up only when these windows are counted from several directions at once.
Advisory device signals
Browser and device attributes are hashed into a fingerprint and weighed alongside form-fill timing and timezone consistency. The signal is the hash, not personal data. They feed the score as advisory input. No device signal decides a transaction on its own.
Lists at two levels
Cards, identification ranges, IP addresses, and devices can be allowed or denied at merchant or platform levels. A merchant maintains its own lists without the operator inheriting them. A platform-level block takes effect everywhere at once without copying into individual configurations.
LAYER 04 · COMPLIANCE
Controls a licensed operator must show
Compliance functions are judged on the record they leave behind. Each control writes what a reviewer later asks for — who decided, on what data, and on what date — into the same database the payment flow uses.
Every control below writes a row of this shape. A rate change, a screening verdict and a refund all leave evidence of one shape, in one table.
Multi-source screening
Fuzzy matching runs against consolidated international lists via structured XML feeds with configurable thresholds. Near misses that fall below the match threshold are not discarded. They carry forward onto the transaction profile as a standing risk signal.
Screening that repeats
Parties are re-screened at capture and refund, not just at onboarding, because a name can be listed between authorization and settlement. If a list refresh fails, the previous list stays in force. Screening continues on stale data instead of stopping.
Review trails
Transaction monitoring looks for structuring and velocity anomalies. Alerts carry the triggering transactions through a strict review workflow with designated approvers. The disposition is recorded next to the evidence it was based on, not in someone's mailbox.
Unified reporting
Threshold-based currency transaction reports and suspicious activity reports are generated from the records the payment flow already writes. The figure in a compliance report and the figure in the operations panel come from one source. They cannot drift.
Requests as cases
Data subject requests for access, correction, and portability are handled as tracked cases with deadlines. Where a record must be kept under a retention obligation, an erasure request is fulfilled in part, and the explicit reason for the remainder is permanently recorded.
Immutable audit trail
Every mutation by a console user, API client, or background job writes an audit row detailing the actor, action, and before/after states. Database triggers protect the table from modification. The application cannot rewrite its own history.
LAYER 05 · WALLETS & MONEY
Wallets, settlement and a ledger
A payment platform is an accounting system. Sum transactions on demand and two reports will disagree. Post every movement, assert it, lock it, and there is one answer — the same answer tomorrow.
BALANCE ASSERTION ON MERCHANT_WALLET
Balances cannot go negative
A database constraint enforces the floor, and the service validates it as well. Every movement asserts the balance before and after. Operations on one wallet serialize with row locking, so two concurrent withdrawals cannot race an account below zero.
Double-entry ledger
Payments, refunds, fees, and reversals post as balanced entries against named accounts. Reports read the ledger; they do not recompute totals on the fly. Platform invoices come from these same postings.
Settlement cycles
Cycles are configured per merchant as next business day, fixed delay, or weekly close, incorporating risk holds. Batches carry running totals. Every entry traces back to the transaction behind it. A merchant questioning a payout gets an itemized answer.
Segregation of funds
Funds held on behalf of customers are tracked separately from the operator's operational funds. They sit in their own ledger, not as a notional share of one balance. Segregation questions are answered with a query.
Wallets as accounts, not counters
Each account holder can hold wallets of their own, with a code, a type and a currency. Merchants, dealers and platform accounts all use the same structure. Settlement credits, fee debits and transfers between holders land as typed movements against a wallet, not as adjustments to a running figure.
The database checks the arithmetic
Every wallet movement stores the balance before it and the balance after it, and a table constraint refuses any row where the two do not reconcile against the amount. A second constraint holds the balance at or above zero. A bug in application code cannot write a wallet history that does not add up.
Deposits, payouts and limits
Wallets take deposits, pay out to saved beneficiaries and carry their own fee rules. Daily and monthly ceilings are configured per holder and per currency, and a movement is refused at the limit rather than clawed back afterwards. Every request carries an idempotency key, so a retry cannot post twice.
Three configured cycles, one batch model
The cycle only changes when a batch closes and when it pays out. What is inside the batch — itemized postings that trace back to a transaction — is identical in all three.
LAYER 06 · ONLINE ACCEPTANCE
Every way a merchant takes a payment
Every channel writes to one set of records. A link, an in-app payment and a hosted checkout run on the same infrastructure. A merchant's approval rate is one number, not several that approximate each other.
For how these channels are packaged for a merchant, see solutions and the sector notes under travel and tourism.
Hosted checkout
A payment page reached by redirect or embedded flow takes its branding and payment methods from configuration, with no per-merchant build. Card data is tokenized at the edge. The operational side never sees a raw card number.
Payment links & QR
Payment requests are delivered as links or QR codes for fixed or open amounts. Links carry expiry parameters, usage limits, and internal status flags. A merchant can check whether a request was opened but left unpaid without building a report for it.
Recurring & dunning
Subscriptions run on stored credentials carrying the specific issuer flags a recurring charge requires. Plans define the interval, retry policy, and grace period. A failed renewal enters a dunning sequence. The subscription is not quietly cancelled and the customer lost.
Native mobile SDKs
iOS and Android SDKs handle card entry on the device and tokenize data before it leaves the hardware. The 3DS challenge renders inside the application. No handoff to an external browser, and no conversion lost at the seam.
Embeddable widget
A JavaScript widget holds card data behind an iframe boundary. The host page receives lifecycle events and a token over a postMessage contract. The merchant application handles the payment result, but the raw card data never touches their DOM.
SHARED BY ALL FIVE
Tokenization at the edge, one risk pipeline, one set of routing rules, one ledger. Nothing about a channel changes what the transaction record looks like afterwards.
LAYER 07 · PHYSICAL ACCEPTANCE
Acceptance in the physical world
Physical acceptance is not an isolated, parallel system. It runs down the authorization, risk, ledger and reconciliation path that online volume already uses. Reporting does not split in two.
SoftPOS
Merchants turn their own Android devices into contactless terminals via a dedicated application. No additional proprietary hardware is required. The application tokenizes at the edge and uses the same routing and risk engine as any online transaction.
Mobile POS
Portable card readers connect to tablets or phones for field operations. Transactions run through the risk and authorization pipeline unchanged. Card data is secured at the read head, which keeps the merchant's phone out of scope.
Physical terminal
Fixed checkout hardware connects directly to the platform API. It settles into the same double-entry ledger as online volume. Every swipe or dip writes to the central event stream, so reconciliation needs no batch file import.
LAYER 08 · OPERATIONS
Running the platform
Most of the cost of operating a payment business is answering what happened to a specific payment. Tooling for operators, support staff, and reconciliation is built into the core from day one, not added as an afterthought a year later.
REDELIVERY — A DOWN WORKER DELAYS, IT DOES NOT DROP
Administration console
Merchants, routing rules, rate tiers, and users are managed from one interface with strict role-based access. Sensitive operations require an elevated role and write an audit row as they go. Changing a merchant's rate leaves the same trace as moving money.
Live operational reporting
Volume, approval rates, decline reasons, and fraud outcomes are read from operational records, not from a delayed analytical copy. Panels update live over server-sent events. An operator watching a decline spike can investigate it while it is still happening.
Access control
Merchant, dealer, and operator users carry distinct role-based permissions, backed by session control. Machine API clients hold their own keys and scopes separate from human sessions. A machine integration cannot inherit a person's permissions, and revoking one leaves the other intact.
Durable event stream
Payment events flow through a durable stream to background workers, outside the synchronous request path. A worker that goes down redelivers on recovery. An outage delays a settlement job; it does not skip one.
LAYER 09 · ARCHITECTURE
Principles the architecture is built on
Architectural boundaries are enforced by guard scripts that run before every commit — payment isolation, handler bypass, card-column checks — not by convention. A rule enforced only by a reviewer is a rule that expires under deadline pressure.
Cloud-agnostic
The codebase runs on private or public infrastructure. Deployment is dictated by data residency policy, not software constraints. Card data is isolated to a separate environment with its own database. The operational side has no code path to a raw number.
Migration-driven schema
Every database schema change is a versioned, forward and backward working migration. Migrations apply in the same order in every environment. There is no manual step. Local development and the production cluster hold the same shape.
Multi-tenant
Merchant, dealer, and sub-account distinctions act as isolated tenants within a single installation. Data access is enforced at the tenant boundary, not left to query discipline. The tokenizer uses envelope encryption and key rotation. Holding the database is not holding the keys.
Service boundaries
Card acceptance, risk, ledger, and reconciliation run as independent services. They scale and version separately, and the build enforces the boundaries between them. Money is decimal everywhere and crosses the API as a string, so no JSON parser rounds it in transit.
API-first & event-driven
Every platform capability is exposed via API. Every transaction writes to an immutable event stream. Reporting, compliance and investigation feed from the same source as the payment flow. An operational view cannot contradict the financial one.
Configuration over deployment
Routing rules, 3DS exemption thresholds, risk scoring parameters, and pricing tiers are all evaluated as runtime configurations. Responding to an acquirer degradation does not require shipping a release. It is a configuration change.
Tell us what you are working with
Launching payments under your own licence, replacing a platform you have outgrown, or adding acceptance to an existing product — describe the setup and we will tell you honestly what fits.
[email protected]