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.

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.

Symptom	An expected auto-pay collection doesn't happen; the customer's payment method shows chargeable: false
Root cause	Rillet's API returns a binary usability flag, not a decline reason
What Rillet's docs say	"Whether the payment method can be used or not. If false, further action from the customer might be required."
What's missing	No expiration date, no decline code, no validation-error field on the payment method object
Only available recovery path	Re-send the customer through the auto-payment setup portal — the same flow regardless of cause

A real limitation, not an implementation gap

This isn't a case where Loopfour's integration could expose more detail and simply doesn't — Rillet's own payment-method API only returns three fields: payment_type, last_four_digits, and chargeable. There's no decline-reason field to read, no expiration date, no validation-error object. The chargeable boolean is the entire status surface Rillet's API provides for a customer's saved payment method.

What this means in practice

An auto-pay collection that should have happened doesn't, and checking the customer's payment method shows chargeable: false. That single bit covers every possible cause — an expired card, insufficient funds, a bank account that was closed, a card flagged for fraud — without distinguishing between them. Rillet's own documentation is explicit that the response to false is generic: "further action from the customer might be required," not a specific corrective action tied to a specific cause.

Why this makes the recovery path always the same

Because there's no cause-specific signal to branch on, a workflow can't build differentiated recovery logic — for example, retrying automatically for a transient failure but escalating immediately for a closed account. The only lever available through the API is the same one used for initial setup: generate a new setup_url and get the customer to visit it again. Any faster or more targeted recovery (a support agent calling the customer, a targeted retry after a few days for what might be a temporary decline) has to be a manual process layered on top, not something the API's own data can drive.

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

Worked example

What a workflow actually sees when auto-pay fails

A customer's card expires on the 3rd of the month. Their next scheduled auto-pay collection is the 5th. The workflow checks the payment method before attempting the charge and sees payment_type: CARD, last_four_digits: 4242, chargeable: false — exactly the same response it would get if the card had instead been declined for insufficient funds, reported lost, or flagged for fraud. The workflow has no way to tell 'this card expired, ask for a new one' from 'this charge was declined, try again in a few days' from the API response alone. The only action available is the same for all four scenarios: generate a fresh setup_url and route the customer back through it.

Frequently Asked Questions

This page covers what the payment-method API itself returns. If Rillet exposes decline-reason detail through a separate event or webhook channel, that's outside the scope of the chargeable field documented here — check Rillet's current API reference before assuming one exists.

Automatic retries can't be targeted without a cause, since the API doesn't distinguish a transient decline from a permanently expired card. A blanket retry risks repeatedly failing against a card that's genuinely gone, rather than catching only the transient cases.

Not from anything documented in the API — the payment method's usability is tied to what's on file, and a false value implies the customer needs to act (update the method through the setup portal), not that the system will self-recover it.

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…

How-to

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.