Search Documentation
Search across all documentation pages
Payment Failures

Payment Failures

When a charge for one of your statements fails, nothing happens all at once. The consequences arrive on a published schedule, every step is reversible by paying, and the dashboard stays readable throughout so you can always see what you owe and settle it.

This page is about a statement we have issued and that has not been paid. For usage that has not been invoiced yet, see Outstanding Balance.

The schedule

Every deadline is measured from the day the payment first failed — not from when we noticed. A delayed check catches up to where the calendar says your account is in one step; it never restarts the clock.

DayWhat changesEmail from Transcodely
0Nothing. The payment provider is retrying on its own schedule.
3Nothing. Still unpaid.
7New jobs are refused. Queued and running jobs finish, outputs are delivered, playback keeps serving, the dashboard stays fully readable.Yes
14The organization is suspended. API keys are refused and public playback stops. Dashboard reads stay open and canceling a job stays allowed.Yes
45Nothing new. The notice names the exact date stored media goes.Yes
60Open statements are marked uncollectible and stored media becomes eligible for deletion. The organization stays suspended.

The failed charge itself is announced by Polar, our merchant of record, which mails you directly and retries on its own schedule. We do not duplicate that message, which is why the first two rungs carry no mail from us — they are the window in which a card that was simply going to work works.

Two things about that table are deliberate:

  • Day 7 stops the hole getting deeper; it does not take away what you already paid for. Killing accepted work would destroy output you may already have been billed for and would not recover a cent of the arrears.
  • Day 14 keeps the dashboard readable. A suspended customer must still be able to see what they owe, pay it, and stop their own meter — so dashboard reads and job cancellation survive suspension.

What day 7 looks like on the API

From day 7, transcodely.v1.JobService/Create — and every path that funnels through it — is refused with Connect code failed_precondition and the error code billing_past_due:

CodeFailedPrecondition
  error-code: billing_past_due
  message: new jobs are paused because an invoice on this organization is
           unpaid; settle it on the billing page and jobs resume immediately
           — work already queued or running is unaffected

Switch on the billing_past_due discriminator, not the message text. Unlike limit_exceeded and queue_limit_exceeded, this one does not clear on its own, so retrying on a backoff asks a question whose answer cannot change. It clears when the statement is paid.

If your account is also over its outstanding-balance threshold, this error is the one you get: it names the remedy that works, and it is the only one of the two with a deadline attached.

Recovery: paying restores service immediately

Payment is the whole reversal, and it does not wait for a nightly sweep. As soon as the statement is marked paid:

  • the episode closes and the ladder resets to its resting state in one step — an account at day 14 does not walk back down rung by rung;
  • any suspension we applied for non-payment is lifted;
  • the deletion clock stops;
  • you get a confirmation email.

New jobs are admitted on the very next request. The dashboard’s billing page reads through a 30-second cache, so it can lag that far behind job creation in catching up.

Two honest limits on that promise:

  • A suspension a person applied stays applied. If your organization was suspended for a reason other than non-payment, paying an invoice does not lift it — that decision was not made by automation and is not undone by it.
  • A write-off is not retracted. Paying after day 60 restores service, but the record that the statements were written off stays; it is a fact about what happened, not a state to be undone.

Disputes and chargebacks

A chargeback is not the same thing as an unpaid invoice, and it is not handled like one. An unpaid invoice is money that has not moved and is being asked for over sixty days. A dispute is money that has already been pulled back by a bank. So there is no ladder and no grace period.

When we learn a payment has been disputed:

  • the organization is suspended, with the same read-only carve-outs as day 14 above;
  • usage that has not been invoiced yet is put on hold rather than billed onward — billing fresh usage from a disputed period is how one chargeback becomes two;
  • you get an email about it, in neutral terms. We do not assume anything about why a dispute was raised.

We learn about disputes from a periodic reconciliation with our payment provider rather than instantly, so the email says nothing about when the dispute was raised.

If the dispute is resolved in your favor, the hold is released — the usage was always billable and we were waiting on a bank — any suspension we applied is lifted, and you are told. If it is not, open statements are marked uncollectible and stored media is scheduled for deletion, with a 90-day retention window counted from the day the dispute was raised rather than from the day it was decided.

An ordinary refund we issue is not a dispute and triggers none of this.

What is not affected

  • Prices never change. What a job costs does not depend on whether an invoice is overdue.
  • Pausing new jobs does not kill accepted ones. Work queued or running when day 7 lands finishes, and its outputs are delivered.
  • Cancel always works. At every rung, including after suspension, you can stop a running job.
  • Billing Standing — how a missing or expired card changes which limits apply, before any statement is involved.
  • Outstanding Balance — the other money gate, for usage not yet invoiced.
  • Errors — the full list of billing-related error codes.