Billing
Customers, invoices, checkout, and money amounts in Vortex Payments.
Billing
Billing flows are customer → invoice (or subscription) → collect / checkout → receipt. The public contract lives under /v1/*.
Core objects
| Object | Role |
|---|---|
| Customer | Who you bill (PUT /v1/customers/{customerId}) |
| Product / price | Catalog you sell |
| Subscription | Recurring entitlement + invoice generation |
| Invoice | Draft → finalize → collect |
| Checkout session | Hosted payment UI |
| Payment request | Recoverable collection for one or more invoices |
| Receipt | Proof of payment |
Money rules
- Store and send amounts as integer minor units (cents for
usd). - Do not use floats,
toFixed, or/ 100in your integration math. - Prefer the generated SDK +
@vortexnyc/moneyin Vortex apps.
Draft to collect
Upsert the customer
PUT /v1/customers/{customerId} with email/name metadata.
Create a draft invoice
POST /v1/invoices with line items in minor units.
Finalize when ready
Use the invoice finalize path from the API reference before collection when your flow requires it.
Collect or open checkout
- Server collect: billing collect routes under
/v1/billing/* - Hosted UI:
POST /v1/checkout/sessions
Subscriptions
Create a subscription with POST /v1/subscriptions, then rely on billing cycles to emit invoices. Change items or status through the subscription change operations in the reference — do not invent a second source of truth in your app.
Tax
Tax quote/finalize is part of the public contract when enabled for your merchant. Keep Avalara (or any tax provider) behind Vortex — your app should only see Vortex-native tax fields on invoices and credit notes.
Explore in the reference
Filter the API for tags like billing, public, and hosted to walk every operation with request/response schemas and code samples.