How do I set up Rillet subscription auto-pay collections?

A workflow calls Rillet's payment-setup endpoint for a customer, which returns a portal URL the customer has to visit themselves to add or update a payment method — Rillet doesn't accept card or bank details directly through the API. Once set up, the method's `chargeable` flag tells the workflow whether it's currently usable, without exposing card-level detail.

By Zuny Fester, Head of Operations and Marketing

Reviewed by Zuny Fester

Published September 14, 2026Last reviewed September 14, 2026Editorial policy

Part of the finance integrations guide.

Endpoint	POST /customers/{customer_id}/settings/payment
What it returns	A `setup_url` the customer must visit to complete or update payment setup
Who provides the card/bank details	The customer, through Rillet's hosted portal — not the API caller
Status field	`chargeable` (boolean) on the payment method — no card number, expiration, or decline detail exposed
Contrast with other AR mechanisms	Dunning-based AR (NetSuite, Sage, QuickBooks, Xero in this matrix) reminds a customer to pay; Rillet auto-pay charges the customer directly on a schedule

This is a genuinely different AR mechanism

Every other ERP integration in this matrix — NetSuite, Sage Intacct, QuickBooks, Xero — handles AR through some form of invoicing and dunning: an invoice goes out, and collections means reminding the customer to pay it. Rillet's integration has a distinct mechanism on top of that: a customer can be set up for subscription auto-pay, where a saved payment method is charged automatically rather than waiting on an invoice reminder. That's a structurally different collections model, not just a different vendor doing the same thing.

The setup flow is portal-based, not a direct API charge

A workflow doesn't hand Rillet a card number. Calling the payment-setup endpoint for a customer returns a `setup_url` — a hosted portal link the customer has to open and complete themselves. If the customer already has a payment method on file, the same endpoint returns a URL to update it instead of create a new one. This matters for workflow design: setup isn't instantaneous from the API caller's side, and there's an unavoidable step where the workflow is waiting on the customer to act in a browser, not just on an API response.

What the workflow can check afterward

Once a payment method exists, a workflow can read it back — the response includes `payment_type` (card, bank account, or other), the `last_four_digits`, and a `chargeable` boolean. That last field is the only usability signal Rillet's API exposes: true means the method can be charged, false means it can't and "further action from the customer might be required." There's no expiration date or decline-reason field in the response — designing a workflow around this means treating `chargeable` as a gate to check before attempting a charge, not as a diagnostic for why a charge might fail.

Next step

Map the finance workflow with the most exposure and prove the automation path.

Bring the invoice, contract, payment reconciliation, or customer finance workflow you have to defend at audit. Loopfour can map the trigger, controls, integrations, and approval loop.

Book a workflow review

Field mapping

Rillet payment-method setup: request vs. what comes back

Step	Call	What you get back
Kick off setup	POST /customers/{customer_id}/settings/payment	setup_url — a portal link the customer must open
Customer completes setup	(happens in Rillet's hosted portal, not the API)	No API response to the workflow at this step
Check status	GET /customers/{customer_id}/settings/payment	payment_type, last_four_digits, chargeable

Frequently Asked Questions

No — Rillet's auto-payment setup always requires the customer to complete a hosted portal flow at least once. The API only returns the link; it doesn't accept payment details directly.

A recurring invoice still requires the customer to take an action (pay it) each cycle. Auto-pay charges a saved, chargeable payment method automatically, without an invoice-then-payment round trip.

Rillet's API doesn't expose an expiration-date field — the only signal available is that chargeable will presumably flip to false, without stating why. See the companion page on what breaks when a Rillet auto-charge is declined.

Sources

Topic

AR & Collections

Accounts receivable is the money customers owe a business for goods or services already delivered on credit — a current asset on the balance sheet until it's collected. AR and collections, as a practi…

How-to

How do I automate dunning and collections reminders?

Schedule reminders relative to the due date (a few days before, then at set intervals after), with escalating tone and channel, and add a suppression check before each send confirming the invoice is still genuinely open and undisputed. Most accounting systems support scheduling this natively; the suppression check is what prevents the most damaging automation failure.

Topic

Integrations

Every finance automation vendor publishes an integrations page: a grid of logos, a claim of "seamless" connectivity, and not much else. That page answers a marketing question — does this vendor touch…

Diagnostic

What breaks when a Rillet auto-charge payment is declined?

Rillet's payment-method API exposes only a binary `chargeable` flag — no decline reason, no expiration date, no validation-error detail. A workflow can learn that a customer's auto-pay method stopped working, but not why, which means the recovery step is always the same generic one: send the customer back through the payment-setup portal, regardless of the actual cause.