Payments
Checkout, recurring billing and the server-side half that decides whether an order was really paid for. Built on your processor account, which you open and you control.
What you get
Why this way
The visible half of a checkout is the easy half. Almost nothing goes wrong at the card field, because the processor wrote that part and tests it against the whole internet. What goes wrong is the quiet half: the webhook that is supposed to come back afterwards and record that the money arrived.
A concrete one from this house. AIRODISC takes cards through Stripe Checkout. When it went live, the payment worked and the confirmation appeared, and the webhook that records the order was being rejected by our own edge firewall, which allowlisted API paths by exact match and did not match that one. Every layer above it reported success. The processor showed a completed payment, the browser showed a completed purchase, and the only place the failure existed was a 403 in a log nobody had a reason to open.
That is the actual work in payments, and it is why we only build on an account you own. When something like that happens on your site, you need to be able to open the processor dashboard yourself and see the truth, without asking an agency for a login.
Live
AIRODISC sells carbon composite wheel discs and takes card payments through Stripe Checkout. Lyra Vital runs a research-supply storefront with customer accounts, a loyalty programme and lifecycle email sitting on top of its payment path. Both are this house’s own properties, which means we carry the consequences of our own payment code rather than describing someone else’s.
airodisc.com ↗Locally
Being in Orlando does not make a webhook more reliable, and it would be a strange thing to claim. Payment code either handles the failure case or it does not, and where it was written has nothing to do with which.
What being here does change is the part that is not code. A shop that takes a deposit at the counter, a card over the phone and a payment online is running three payment paths that have to end up agreeing with one another and with whatever it runs the business on. Sorting that out means standing where the terminal is, watching how a service writer actually takes a deposit, and finding the step that never gets recorded. Orlando, Winter Park and the rest of Orange and Seminole counties are a drive, so that is an afternoon rather than a series of calls about what someone thinks happens.
Questions
No. This house is not a merchant services provider, does not place merchant accounts, and takes no residual on anyone’s processing. You open the account yourself, in your own name, directly with the processor, and we build everything on top of it. An agency that arranges your processing is holding the account the money lands in, which is the single worst thing to have to ask someone else for.
Stripe by default, because it is what we have shipped and what most of these builds need. If you already run something else and it works, the usual answer is to build on it rather than move you, and we will say so. Migration is worth doing when the current processor is actually costing you something specific, not because we prefer a different dashboard.
You do. Funds settle from your processor account to your bank account and never pass through us at any point. We have no access to your balance and no ability to move it. If you end the relationship, payouts are unaffected, because nothing about them was ever routed through this house.
A hosted or processor-hosted checkout keeps card numbers off your servers entirely, which normally puts you in the lightest self-assessment category rather than a full audit. We will tell you plainly which one applies to your setup. If a build genuinely needs card data to touch your own infrastructure, that is a much larger compliance commitment and we will say so before you spend anything, not after.
Yes, as help rather than as a broker. We will sit with you while you open it, tell you what the application is actually asking for, and stay with it until a first live transaction goes through. The account is opened by you, in your name. Approval is the processor’s decision and not something anyone can promise you or influence on your behalf, so treat a guarantee of approval as a reason to walk away.
The number that matters is the effective rate, which is total fees divided by total volume over a real month, and it is almost never the rate you were quoted. A flat rate bundles interchange, the card network’s assessment and the processor’s margin into one figure, which is simple and usually costs more as volume grows. An interchange-plus arrangement shows you the three separately. We will work the effective rate out from your existing statements before anyone recommends changing anything.
Sometimes, and the rules are stricter than most people are told. Card networks treat a surcharge on credit as a distinct thing from a discount for cash, they cap it, they require disclosure at the point the customer decides, and they require you to notify the network beforehand. Debit is treated differently again. State law also bears on it and has changed in several states. Confirm the current position with your own processor and, where the money is material, your own advisor. We will build whichever model you land on correctly, and we will not tell you it is free money, because the chargeback and goodwill cost is real.
The processor pulls the money back and asks you for evidence, usually on a short clock. Almost all of that fight is won or lost by what your system recorded at the time: what was authorised, what was captured, what the customer agreed to, and when. Most shops lose disputes they should win because nobody stored the authorisation or the acceptance. Building that record in from the start costs very little; reconstructing it afterwards is usually impossible.
Usually not, and replacing a working terminal is rarely where the money is. The common problem is that the counter and the website are two separate payment systems that never agree, so somebody reconciles them by hand every month and deposits get matched to jobs by memory. Making those two agree is normally worth more than changing either one.
A straightforward checkout on an existing site is usually days rather than weeks. Subscriptions, stored cards, deposits against jobs, or making a counter system and an online system reconcile are longer, because the work is in the failure cases rather than the happy path. We will tell you which of the two you are asking for before you commit to anything.
Often, and it is a common way this starts. The usual findings are the same few things: a webhook that is not signature-verified, no retry or logging so silent failures are invisible, and tax or shipping calculated in two places that disagree. We will tell you what is actually wrong before proposing a rebuild.
Related reading
Taking new work
Send what you have and what is not working. You will get a straight answer about whether this house is the right fit, including when it is not.