Skip to main content
Every Modem Pay invoice exists in one of four states. Understanding these states is crucial for building reliable subscription and billing systems.

The Four States

1. Draft

Initial state for unpublished invoices An invoice in draft state has been created but not sent to the customer. Characteristics:
  • status: draft
  • sent_date: null
  • Customer has not been notified
  • No payment link active
  • Can be modified freely
Use Cases:
  • Review invoices before sending
  • Batch preparation of monthly invoices
  • Approval workflows
  • Price calculations that need verification
Example:
nodejs

2. Not Paid (Published)

Active invoice awaiting payment The invoice has been sent to the customer and is awaiting payment. Characteristics:
  • status: "not-paid"
  • sent_date: <ISO timestamp>
  • paid_date: null
  • Customer has received email notification
  • Payment link is active
  • Can still be updated (with caution)
Use Cases:
  • Standard invoice flow
  • Active subscription billing
  • Pending payments
  • Awaiting customer action
Example:
nodejs
Monitoring:
nodejs

3. Paid

Invoice successfully paid Payment has been received and confirmed. Characteristics:
  • status: "paid"
  • paid_date: <ISO timestamp>
  • Payment link no longer accepts payments
  • Final state (cannot transition back)
  • Triggers paymentrequest.success webhook event
Use Cases:
  • Successful subscription payment
  • Grant service access
  • Generate receipt
  • Update billing records
  • Provision resources
Example:
Webhook Handling:

4. Overdue

Payment deadline passed without payment The due date has passed and the invoice remains unpaid (production mode only). Characteristics:
  • status: "overdue"
  • paid_date: null
  • Due date has passed
  • Only in production mode (not test mode)
  • Automatically set at midnight on due date
  • Triggers invoice.overdue webhook event
  • Can still transition to paid
Use Cases:
  • Subscription payment failures
  • Grace period enforcement
  • Service suspension
  • Collections process
  • Dunning management
Example:
Production Only: Overdue detection only works with live API keys (sk_live_). Test invoices never become overdue, allowing safe testing without time constraints.

State Transitions

Creating Invoices

Direct Creation (Published):
nodejs
Draft Creation:
nodejs

Publishing Drafts

nodejs

Payment

nodejs

Overdue Detection

nodejs

Timeline Example

Here’s a complete subscription invoice lifecycle:

Working with Invoice States

Checking Current State

nodejs

State-Based Business Logic

nodejs

Subscription State Management

nodejs

Important Timestamps

Invoices track several key timestamps:
nodejs

Test Mode vs Production

Test Mode Behavior

nodejs

Production Mode Behavior

nodejs

Best Practices

Don’t poll for status changes. Implement webhook handlers for paymentrequest.success and invoice.overdue events for real-time updates.
For subscriptions, set due dates 7-14 days after invoice creation to give customers time to pay. For monthly billing, due date should be before the next billing cycle.
Don’t immediately suspend services when invoices go overdue. Implement a 3-7 day grace period with automated reminders before taking action.
When generating invoices for many customers, create drafts first, review for accuracy, then publish in batches.
Monitor reminder_count to avoid spamming customers. Implement logic like: reminder at 7 days before due, at due date, and 3 days after due date.
Test your entire flow in test mode before going live. Remember: test invoices never go overdue, so test overdue logic separately.

Common Patterns

Subscription Billing State Machine

nodejs