Processing for live books
See the payment. Then see the money land.
VaultPay is the layer between your checkout and the acquirer. Deposits, payouts, and the daily close sit on one desk, whether you run brands, a provider book, or a platform other companies sell.
A slow payout or a sudden drop in accepted deposits is not a technical footnote. It is the day’s revenue. VaultPay is arranged so the people who own that number can see the path, the funds, and the exception in the same place.
What clients measure
Four numbers the desk actually watches.
Not a slide. The same figures finance and operations argue about after a busy weekend.
Three kinds of book
Same rails. A different job for each.
Operators live in the player session. Providers live in the merchant list. Platforms live in the tenant. The processing underneath is shared.
Brands
Operators
Deposits, withdrawals, and the fraud checks around them. Built for several brands that share a treasury and cannot wait on a manual close.
- No extra processor in the middleThe brand connects straight in. Go-live is shorter, and the cost per merchant stays visible.
- One close for every brandPayout files and the matching report land together, across the portfolio.
- Checkout in the local currencyPlayers pay in the currency they already hold, on each brand you run.
Merchant books
Providers
You sell processing. Your merchants judge you on accepted payments, when they get paid, and whether anyone picks up when a batch fails.
- Route on what is working nowA payment moves to the acquirer path that is clearing, not the one from last quarter’s setup.
- The whole portfolio in one viewSettlement and open items for every merchant, not a folder per client.
- Exceptions already matchedCurrency and brand differences are lined up before someone opens a spreadsheet.
Tenants
Platforms
Your clients expect payments inside the product you already sold them: an API, a webhook, and a statement that belongs to their tenant alone.
A demo can look finished. A Saturday night of deposits will tell you if it is.
Two clocks
Where the payment goes, and when the cash returns.
Routing decides the attempt. Settlement decides the week. VaultPay keeps both on the same book so they do not drift apart.
Settlement
Cash on a date you already know.
The payout date is agreed up front. The file that explains it shows up with the money, so treasury is not reconstructing the day from five exports.
- CadenceAgreed in advanceSet
- ReportDelivered with settlementSynced
- ExceptionsMatched across brandsFlagged
Routing
The next attempt follows the last result.
Card issuer, currency, and ticket size pick the route, then the accept and decline stream updates it. You are not locked to yesterday’s acquirer mix.
- Approval pathChosen in real timeLive
- Exception matchAcross currenciesAutomated
- Brand reportSame clock as settlementSynced
Volume
Made for yearly flow counted in hundreds of millions.
Your operation sends the payment. VaultPay chooses the acquirer. The result — accepted, declined, or held — comes back into the same book your team already works from.
01The checkout or the payout
02VaultPay picks the route
03The acquirer, then the result
A first call
Bring the volumes. We will bring the questions.
Brands, rough monthly flow, and where deposits or payouts hurt today. A reply comes within one business day.