Saved bills & autopay
Where saving billers and running recurring payments lives today — and where Billy is headed.
Today: your app owns it
Billy is stateless with respect to your end-users. It does not store which billers a given user has saved, their account numbers, or any payment schedule. Your app owns that data and decides when to call Billy.
A typical pattern:
- Store the biller's
public_idand the user's account fields in your own database. - When a bill is due, quote the amount and post a payment, passing your user's
external_customer_ref. - Run your own scheduler for recurrence, retries, and reminders.
This keeps you in control of your customer relationship and your data, and keeps sensitive account details in a system you already secure.
Why we designed it this way
Storing end-user account details and running a payment scheduler are meaningful data-privacy and reliability commitments. Rather than impose Billy's model on every integration, we keep the core API lean and let you build recurrence the way your product needs it.
On the roadmap
Two optional, opt-in capabilities are planned as premium tiers. The external_customer_ref and idempotency key you already send are the join keys they'll build on — so adopting them now costs nothing and future-proofs your integration.
| Capability | What it will offer |
|---|---|
| Billy Vault | Store saved billers and account references against your external_customer_ref, so you don't have to hold them yourself. |
| Billy Autopay | Schedule recurring payments — Billy runs the scheduler, retries, and notifications on top of the Vault. |