How it works
Secure handoff, end to end.
The customer never leaves a certified surface. The merchant never touches raw card data. Every movement of money leaves a record that gets matched the next morning. This page walks the whole path — including what we deliberately do not do.
Customer → hosted provider checkout → provider settlement → merchant account
Stage 01 · Hosted payment surface
The customer pays on certified infrastructure.
Checkout, invoices, and payment links all resolve to a payment surface run by a certified payment provider. The experience is branded like the merchant's business up to the moment of payment — and at that moment, the card fields belong to the provider, not to us.
"Hosted" means exactly this: when the customer types a card number, it goes into the provider's certified systems. Not a form we run. Not a server we operate. We never see the number, and PCI scope stays with the processor. That is not a limitation we tolerate — it is the design. The product Apex Pay builds is everything around that moment: what leads the customer there, what confirms the payment, and what records the event for the book.
The seam is the point: everything above it is our product, everything below it is the provider's certified infrastructure.
Stage 02 · Settlement on provider rails
Money settles on the provider's rails.
Capture, payout timing, and account routing follow the provider agreement the merchant signs. We make the flow legible. We do not set the terms — and we will not pretend to.
Stage 03 · Daily reconciliation
Every day, the book is matched.
Five records, matched daily: sessions, captures, refunds, disputes, payouts. Each capture ties back to a session. Refunds net against captures. The payout the provider settles is compared to the payout the ledger expects.
Most days look like this. Captured minus refunds equals what settled, and the day closes balanced.
The interesting day. A $14.63 gap, traced to a refund that crossed the provider's payout cutoff, documented, and carried to the next payout. Figures illustrative.
The rule is simple: variance is chased the day it appears, not at month end. Most variance is timing — something crossed a cutoff. The point of matching daily is that when it is not timing, the problem is one day old when we find it, not thirty.
Stage 04 · The merchant view
One view of the book.
Everything the first three stages produce lands in a single view, organized around the four questions a merchant actually asks.
Moved
What moved
Everything captured today, each amount matched back to the session that produced it. No orphan charges.
Settled
What settled
What actually landed in the merchant account, lined up against what the provider agreement said to expect.
Attention
What needs attention
Open disputes with their deadlines, unmatched refunds, any variance — each with a cause and an age in days.
Next
What happens next
The next expected payout and what is inside it, so tomorrow's bank line is known tonight, not discovered at lunch.
The map
Where Apex Pay sits.
The money flow has four stops, and Apex Pay is none of them. Funds move from the customer to the provider to the merchant's own account. We build the product layer on top and operate the visibility around every arrow.
Not in the money flow
We are not a bank, not a money transmitter, not a processor, and never a stop the money passes through. If a payments company cannot say that sentence plainly, ask why.
We build what brings them here: the checkout, the invoice, the payment link — branded like the merchant's business.
We record the session and watch the capture. Card data goes to the provider; a record of the event comes to the book.
We track expected against actual — payout timing per the agreement, amount against the ledger, variance flagged same day.
The solid line is the money: four stops, none of them ours. The dashed lines are Apex Pay — connected to every step for the record, part of none of them for the funds.
Straight answers
Questions we want you to ask.
Do you store card data?
No. Card data is entered on and held by certified payment providers. The fields the customer types into belong to the provider's certified infrastructure — it never touches Apex servers, and PCI scope stays with the processor.
Are you a bank or a payment processor?
No. We build products and operations on hosted provider rails. We do not hold funds, process cards, or sit anywhere in the money flow. Funds move from the customer to the provider to the merchant's own account.
Who underwrites merchants?
The payment provider. Underwriting is their decision under their criteria. What we build is the onboarding experience around those requirements — so the application arrives complete the first time and the decision is not delayed by a paper chase.
What do you actually provide?
Three product areas. Merchant onboarding experiences. Hosted checkout, invoicing, and payment links on certified provider rails. And operational visibility: payouts, refunds, disputes, variance, and daily reconciliation in one view.
What does reconciliation cover?
Sessions, captures, refunds, disputes, and payouts — matched every day. Expected payout is compared against actual, and variance is chased the day it appears, with a cause attached, not carried silently to month end.
Can you work with our existing payment provider?
It depends on the provider, so it starts as a conversation. We evaluate three things: hosted payment surfaces we can build on, event records we can reconcile against, and payout reporting we can match. Where those exist, usually yes. Where they do not, we will say so before any work starts.
How do we start?
Talk to us. Tell us how money moves through your business today. We map the flow, name what fits, and scope the product that keeps it visible and reconciled. Start here or email support@apex-pay.co.
Get started
Walk us through your flow.
Thirty minutes. You describe how money moves through your business; we tell you what we would build around it — and what we would not.