Send it once. Flint does the chasing.

Cards, Apple Pay, Google Pay, Affirm, and ACH debit, on a hosted page Flint emails for you. You choose the set per invoice with the payment policy, and it is frozen on the invoice at issue. A payment option limit hides an option once the invoice total passes the cap you set, so large invoices go to bank debit. With the cost comparison on, the page tells the buyer what paying by bank saves. ACH debit that is still processing shows the buyer the expected settlement date on the page.

Yes. Create the invoice with automatic collection and a saved payment method, and issue freezes that method onto it. The collect endpoint charges it off-session, and a decline retries on the day offsets in your autopay retry policy without another call from you. Every attempt, including the declined ones, is a record you can list. Autopay runs on reusable saved cards; ACH debit and Affirm invoices collect through the hosted page.

Yes. Send schedule entries on the draft: a deposit due at issue or on a date, installments on dates, and a balance on the invoice due date, each as a fixed amount, a percentage, or the remainder, up to 14 entries. The hosted page asks for what is due now rather than the whole balance, currently_due_money tells you the same figure, and each entry carries its own paid, credited, and outstanding amounts. Leave the array out and the invoice is due in one payment on its terms.

The payment term carries the policy, fixed or a percentage, with a grace period. Once that period passes with a balance remaining, Flint computes the fee from what is still owed and tells you with an event. Charging it is your call: one request assesses the fee onto the invoice, which raises the amount due and prints a dated addendum on the hosted page and the PDF, while the issued lines, tax, and original total stay fixed. Waive the unpaid remainder with a reason only you can see, and the fee's own paid, waived, and outstanding amounts stay on the invoice.

Reverse it. The reverse endpoint takes the amount and the check's reference and puts the balance back, on a paid invoice as well as an open one, so a check that closed an invoice and then returned unpaid reopens it correctly. Status follows the money in both directions. A reversal only undoes recorded offline amounts, never card money, and it cannot exceed what was recorded, so a card payment is never quietly undone.

On the schedule you write, as day offsets from the due date, negative ones before it. Flint sends each reminder for you with the live payment link, in the invoice's timezone, and freezes the list onto the invoice at issue so a later settings edit never rewrites a receivable already out. When the customer replies, pause the cadence on that invoice with one call and resume it later; a one-off send-reminder still works while it is paused. Every reminder is also a webhook event, so a caller-managed invoice can send from your own system on the same cadence.

The first time the customer opens the hosted page stamps viewed_at on the invoice. Every send and every reminder is a delivery attempt with a status and, when it fails, the reason, and invoice.delivery_failed fires on a bounce. The invoice's own event log holds the rest: issued, viewed, each payment, each reminder, each reversal, with the actor and the time. When a customer says they never got it, the conversation ends there.

A credit note reduces what is owed. A refund returns what was collected. Credit the lines that were wrong and Flint computes their share of discount and tax, numbers the credit note with your prefix, renders a PDF the customer's accounts-payable team can file against the original, and draws the credit down against the balance when you allocate it. If the invoice was already paid, refund the credit note instead: the money goes back to the original payment method, and the refund stays linked to the note and the invoice. The invoice tracks refunds separately from its status, so a paid invoice stays paid.

Yes. A customer signed in to the account Flint hosts sees every invoice you have sent them, pays the open ones, and downloads the PDF and any credit notes. If an emailed link was forwarded somewhere it should not have been, regenerate it: the old link and any checkout credentials taken from it stop working immediately, a payment already in flight survives, and every reminder after that carries the new link.