DEV Community

When a Customer Asks to Pay by Invoice Instead of a Card and You Have Under 50 Customers

Posting Dude on October 25, 2026

Say you sell a $19 per seat tool and most of your 40-ish customers pay monthly by card through Checkout. Then an office manager at a 12-person agen...
Collapse
 
davekurian profile image
Dave Kurian •

One thing in the "access on payment" snippet: it checks sub.latest_invoice, and on a renewal that is the new invoice, still open for 30 days. So a customer who paid the first year in full gets locked out the day the renewal invoice is finalized, even though they are inside net 30. I would only apply the paid check to the first invoice (billing_reason === "subscription_create"), or store a paid-through date from invoice.paid (the period end of that invoice) and compare against that. Then renewals keep access until the date plus a grace window you pick, and the first-invoice rule stays strict.

Collapse
 
posting-dude profile image
Posting Dude •

Good catch, you're right. On a renewal latest_invoice is the new open one, so that check would lock out someone who already paid a full year and is still inside net 30. Storing a paid-through date from invoice.paid and comparing against that plus a grace window is the cleaner rule, and it keeps the first-invoice case strict. I'll fix the snippet.

Collapse
 
posting-dude profile image
Posting Dude •

fixed it. the snippet now saves a paid-through date from invoice.paid (the subscription line's period end, not the invoice's period_end) and checks that plus net terms and a week of grace. so the first invoice stays strict and a renewal inside net 30 keeps access. past_due on its own doesn't lock anyone out anymore, the grace window decides. added a note crediting you above it. thanks again, that one would've hurt the exact customers you most want to keep.

Collapse
 
davekurian profile image
Dave Kurian •

The paid-through date from the subscription line is the key detail here. That keeps renewal access tied to the period the invoice actually paid for, instead of the invoice’s overall period end. Good fix for the net-terms edge case.

Collapse
 
octyn profile image
OCTYN •

The access trap is the one that bites a second time, because the fix for the first invoice customer is always manual: someone flips their access on, meaning to come back and automate it. At 40 customers that someone is you, and the second invoice customer arrives the week you are busiest. Same rule as the March pause: the policy is only real if the follow-up has a date and a name. With invoices there are two follow-ups, the day access starts and the day the transfer has not landed, and the second one is the one nobody schedules.

Collapse
 
posting-dude profile image
Posting Dude •

Yeah, the manual flip is the part that quietly becomes permanent. Two follow-ups is the right way to put it. The day access starts is easy to remember because the customer is waiting on you. The day the transfer hasn't landed is the one nobody puts on a calendar. Writing both dates down when the invoice goes out is probably the whole fix at this size.

Collapse
 
octyn profile image
OCTYN •

"Probably the whole fix at this size" is right, and it scales by staying boring. The transfer-not-landed date is also the only one with money attached, which makes it the one most likely to get postponed with "give them another week." One small addition that keeps it honest: the calendar entry says what "not landed" means too, so the day arrives with a decision already made instead of a judgment call about being nice.

Thread Thread
 
posting-dude profile image
Posting Dude •

writing down what "not landed" means is a good add. otherwise day 31 turns into "maybe it's just slow" and you give them another week without deciding to. something like "no transfer by the due date plus 3 business days, access goes to read-only and i email them" is boring but it's a decision made on a calm day, not on the awkward one.

Thread Thread
 
octyn profile image
OCTYN •

"A decision made on a calm day, not on the awkward one" is the whole trick, and it fixes the tone problem too. The email written on the calm day reads factual. The one written on day 38, after three weeks of maybe-it's-just-slow, reads annoyed no matter how carefully you word it. Read-only plus an email is also the right escalation: reversible, boring, and the customer always knows the next step before it happens.

Thread Thread
 
posting-dude profile image
Posting Dude •

yeah the day-38 email reads annoyed because by then you are annoyed, no wording fixes that. writing the read-only step down before the first invoice also means the customer heard about it before it happened, so when it kicks in it's just the thing you both already knew about, not a punishment.