Payments & Billing

What it is

Payments and billing is everything it takes to charge money inside your app: one-off checkout, recurring subscriptions, invoices, and a record of every transaction. On ybuild it's built into the app and connected to a real payment processor, so customers pay you directly. Plans, pricing, and receipts come from your description.

Why it matters

A business system that can't take money isn't a business yet — it's an admin tool. Billing that lives inside the same running app means payments are tied to your customers and their data, not bolted on through a separate tool you reconcile by hand. That's what turns the system into revenue.

How it works on ybuild

Tell ybuild what you charge for and how, and it wires checkout, subscriptions, and invoicing into the live app. Everything is hosted on ybuild and served on your domain, so customers pay on your site and the money lands in your connected account. Transactions are recorded in your app's own database, right next to the customer they belong to.

What actually happens when a customer pays you

When someone taps 'Pay' in your app, a lot happens in the second before the receipt appears — and the most important part is what your app deliberately never sees.

The card details are captured in a field that belongs to the payment processor, not to your app's code. The moment they're entered they're sent straight to the processor and swapped for a token — a harmless reference, like a coat-check ticket, that stands in for the real card. Your app stores and works with that token; the raw card number never touches your server or your database. That single design choice is what keeps you on the shortest compliance path the card networks define (the SAQ A tier) instead of the audit-heavy world of handling card data yourself.

With the token in hand, the processor asks the customer's bank to authorize the charge — a hold that checks the card is real and the funds are there — and then captures it to actually move the money. For customers in Europe and the UK, the bank may trigger a Strong Customer Authentication step: a 3D Secure challenge, like a banking-app tap or a one-time code, that regulation requires on many card-not-present payments. When it passes, the charge clears and the customer never leaves your domain.

Here is the part most do-it-yourself builds get wrong: the redirect back to your success page is not proof of payment. The reliable confirmation is a webhook — a signed message the processor sends your backend saying the charge succeeded. ybuild wires that listener up, verifies the signature, and only then writes the transaction into your app's database, next to the customer it belongs to. Repeated deliveries are made idempotent, so a webhook that arrives twice can't count the payment twice. The result is one record of truth: the customer, the plan, and every charge living together in the same running system, not scattered across a processor dashboard you reconcile by hand.

Building billing yourself vs. getting it on ybuild

It's worth being blunt about the do-it-yourself path, because billing is one of the deepest rabbit holes in software.

Rolling your own, 'accept payments' expands into a project of its own: integrate the processor's SDK, build a checkout that handles the 3D Secure challenge flow, stand up a webhook endpoint with signature verification and idempotency, then reconcile what the webhook says against what your database thinks. Subscriptions turn that into a state machine — trials that convert, plans that upgrade and downgrade mid-cycle, proration math, pauses, cancellations, and reactivations, each with its own edge cases. On top of that sits the unglamorous half nobody demos: retrying failed cards, dunning emails, refunds, prorated credits, chargeback and dispute handling, invoices with sequential numbers, and sales-tax or VAT calculation that changes with where the customer sits. Every one of those is a place money leaks or a customer gets wrongly charged.

On ybuild, you describe what you charge for and how — 'a $29/month plan with a 14-day trial and an annual option,' 'a one-off checkout for each order,' 'invoices due net-30' — and it wires checkout, subscriptions, invoicing, and the webhook plumbing into the running app. It's built as a hosted full-stack system: the billing logic, the customer records, and the database live together and go live on your own domain. Customers pay on your site, and the money lands in your connected processor account.

The distinction isn't just up-front effort. A hand-built billing stack is permanent operational surface — someone owns the webhook that silently stopped firing, the renewal that double-charged, the tax rule that changed overnight. Because ybuild hosts the app and keeps the pieces wired together, changing a price or adding a plan is a sentence, not a migration. You own the part that makes money — the customers, the revenue, the domain — and the plumbing underneath is the platform's job.

The gotchas that bite live billing, and what it means for the business

A handful of edge cases catch almost every team that runs billing, and they're worth naming because a live system meets all of them.

Failed renewals are the quiet one. Cards expire, hit limits, or get falsely declined, and subscription businesses lose roughly 9% of monthly recurring revenue to failed payments, with industry failure rates running 5-15%. Most of that is recoverable — but only if something retries intelligently and emails the customer; without dunning, the revenue just evaporates. SCA declines are the European cousin: a payment that would have cleared gets blocked because a 3D Secure step was never offered, so the challenge flow has to be built in, not bolted on. Idempotency matters more than it sounds — a network hiccup can make a charge request arrive twice, and without a guard the customer is billed twice and disputes it. Webhooks, not the browser redirect, are the source of truth, so a build that marks orders 'paid' on the thank-you page will book phantom revenue the instant a card is declined after the redirect. And tax follows the customer's location, not yours, which quietly turns a simple price into a compliance question the moment you sell across borders.

What you get for handling all of that correctly is the thing that makes a system a business. Billing that lives inside the same app means every charge is tied to the customer and their data — you can see who's on which plan, whose card is failing, and what each account is worth, without exporting a CSV and matching it against a processor dashboard. MRR, churn, failed-payment recovery, and lifetime value stop being spreadsheet guesses and become properties of the running system.

That's the difference between an admin tool and a company. A prompt-built app that takes money on your own domain, records it next to the customer, and keeps subscriptions alive through the messy middle is a revenue engine you can actually run — hosted on ybuild, on your address, with the money landing in your account from day one.

FAQ

Do I need my own Stripe or payment account to take money?

You connect a payment processor account, and that's where your money lands — it stays yours. ybuild builds the checkout, subscriptions, and invoicing into your app and wires them to that account, so customers pay you directly on your own domain. You don't write the integration or babysit the webhooks; the platform keeps them running behind the live app.

Is it safe to take card numbers in a ybuild app?

Yes, because your app never touches the raw card number. Card details are captured in the processor's own secure field and swapped for a token before they reach your code, so sensitive data stays off your server and out of your database. That keeps your app on the card networks' shortest compliance path (SAQ A) instead of the audit-heavy tier meant for merchants who store card data themselves.

Can I run subscriptions with free trials, upgrades, and cancellations?

Yes. Describe the plans — monthly and annual, a free trial, tiers customers can move between — and ybuild builds the recurring billing, trial conversion, proration for mid-cycle changes, and cancellation into the live app. The subscription state lives in your own database next to the customer, so you always know exactly who's on which plan.

What happens when a customer's card is declined at renewal?

The app retries and follows up instead of silently losing the revenue. Failed renewals cause subscription businesses to lose around 9% of recurring revenue industry-wide, and most of it is recoverable with smart retries and dunning emails — so ybuild builds that recovery flow in. Because billing sits inside your app, you can see exactly which accounts are failing and act on them.

Can it handle invoices and sales tax?

Yes. ybuild builds invoicing — sequential invoice numbers, due dates, receipts — into the app, and can apply sales tax or VAT based on where the customer is, since tax follows their location rather than yours. Everything is recorded in your app's database and served on your own domain, so your billing records and your customer records are one system, not two you reconcile.