Billing

A failed or past-due payment#

Open Billing and the outstanding invoice. Use the payment action shown for that invoice and complete any provider authentication. If the outcome is unclear, check invoice status before paying again. For a manual transfer, upload the requested proof and wait for review.

Plans and changes#

Check the current price, server count, renewal date and cancellation terms in Billing before confirming a change. Save the invoice reference for support. Never send full card details, bank passwords or authentication codes.

Identify the debt before paying#

In Billing, review the account, plan, billing period, amount and invoice reference. Changing a plan, making a new purchase and settling an existing subscription’s overdue payment are different operations. For past due, use the recovery workflow for the existing debt first.

Choose a method actually offered for your account and transaction on the payment page. Complete any card or provider authentication on the provider’s own page. Keep passwords, full card details and one-time banking codes out of support requests.

Read the open invoice’s current status before starting. If a teammate has already paid, refresh instead of using a button in an old tab. If the account warns about multiple linked provider subscriptions, ask support to review those records before creating another subscription.

Use Pay now / update payment method for past due#

For an overdue or on-hold subscription, the displayed Pay now / update payment method action opens the recovery workflow of the existing provider subscription. Do not treat each click as a reason to purchase a new subscription.

1. Open Billing, review the relevant subscription and debt, and use its existing payment recovery action.
2. On the provider page, complete payment-method updates and required authentication. If the page fails or expires, check the latest transaction outcome with the provider.
3. Return to the panel and refresh invoice and subscription status. Returning from the provider alone does not prove the payment was confirmed.
4. If the result is uncertain, do not start a second payment. Contact support with the invoice reference, time and error text with secrets removed; do not automatically retry an ambiguous timeout.

Submit a transfer receipt for the correct invoice#

If manual payment is offered, read recipient and reference details from that invoice. After transferring, upload a readable receipt to the same invoice. Accepted content is JPEG, PNG, WebP or PDF, with a 5 MiB maximum. Renaming an extension does not make unsupported content valid.

A submitted receipt waits for review; uploading it does not automatically mark the invoice paid. Follow the review result instead of repeatedly submitting the same pending proof. If rejected, read the explanation and prepare a suitable replacement, excluding bank passwords and unrelated account details.

Receipt access is authorized. Avoid sharing its file link in a public channel when requesting help, and never submit another account’s proof or attach it to the wrong invoice. If upload fails, check the content type, size and whether the invoice is still unpaid.

Review cancellation and support details#

An outstanding recurring subscription debt managed by Dodo or Stripe does not disappear by cancelling a local invoice record. Use the subscription-management workflow and review its displayed terms. Distinguish payment recovery, plan changes and cancellation outcomes.

• Refresh the invoice and subscription status after the payment attempt.
• Do not create a second transaction for an uncertain result; follow any pending receipt review.
• Review the renewal date, billing period, current amount and plan limits.
• Give support the invoice reference and error time, excluding full card details, banking codes and passwords.

Distinguish a rejected payment from an unknown result#

A provider rejection, a page that failed to open and a timeout after authentication require different next steps. Read the message and check whether the provider created or completed a transaction. A blank return page does not establish that no money moved, and a successful bank authentication does not independently establish that the invoice was paid.

For an explicit rejection with no successful transaction, use the provider’s explanation to resolve the payment-method issue. If the result is pending or unknown, inspect the existing transaction and refresh Billing before attempting another charge. Ask the person who owns the payment method to verify its status privately.

For support, record the invoice reference, provider, approximate time, currency and masked error. Explain whether authentication completed and whether any transaction reference exists. Exclude full card numbers and banking codes. This lets support reconcile one attempt instead of investigating several overlapping payments.

Recover an old subscription without creating a duplicate#

Suppose Billing displays past_due and you want to restore the same subscription. First confirm that the debt belongs to that subscription and use its Pay now / update payment method action. Payment recovery resolves or manages the provider-linked record; buying another plan is a different operation with separate consequences.

If the recovery page cannot open, check that your account has billing-management permission and that the browser session is current. Reopen Billing from normal navigation before submitting again from an old tab. If a linked-subscription conflict is displayed, preserve the message and ask support to review the linked provider records.

After provider recovery, compare the open invoice, subscription status and renewal information. If the provider confirms success while the panel remains overdue, supply the existing reference and time for reconciliation. Do not cancel a local invoice or open a second subscription to conceal the unresolved state.

Coordinate payment work within the team#

Assign one authorized person to handle an outstanding invoice and tell teammates which invoice is being reviewed. Before any attempt, check the current status and confirm no other person is already completing that payment. A shared screenshot from earlier in the day may no longer reflect the live invoice.

For manual transfers, ensure the receipt corresponds to the invoice’s amount, recipient and reference. A pending review should be tracked as pending rather than treated as failure or repeated through another method. If the method or amount appears unsuitable, clarify that invoice before transferring money.

After the result is confirmed, record the paid invoice reference, method category and completion time without retaining sensitive payment credentials in team chat. If a cancellation or plan change is also needed, review it as its own action. Clear ownership reduces accidental duplicate attempts and makes a later billing inquiry easier to resolve.

Separate capacity limits from payment status#

Before adding a server or website, read the usage and limit values in Billing together. Servers, sites, users, API keys and storage are separate categories; spare capacity in one does not establish entitlement in another. Your payment may be current while your site allowance is full. Authenticating the card again or paying the same invoice again does not automatically create more site capacity.

Write the actual task: add a server, create a website or invite a teammate. Check that category’s used and permitted values. When examining an add-on or plan offered to your account, read the limit it changes and the displayed amount. Do not assume an unlisted service is included. Reviewing an option does not itself mean purchasing it.

If the records disagree, prepare the category, current value, expected change and last confirmed invoice reference for support. Player count and the panel’s server allowance measure different things. Identifying the required capacity first helps determine the right action without unnecessary payment attempts.

Match invoice rows by period and currency#

Read invoice number, period, amount, status and payment date together. Two rows with the same amount may cover different periods; do not identify them as the same debt from amount alone. Note the invoice reference and currency. If no period is displayed, report that absence rather than inventing dates. Payment date and service-period start are different information.

Create a short reconciliation note: which invoice did you open, what period and status did it display, and what reference identified the corresponding provider transaction? Local records can show paid, refunded or void; do not reduce them all to “complete”. Do not infer the relationship between a refund and another outstanding invoice from the badge colour.

Remove full card details, banking credentials and unnecessary receipt information before sharing the note. Describe provider and panel outcomes separately. The purpose is to associate existing records with the correct debt; deleting records, paying another period or opening a new subscription does not validate that association.

Check three records after returning from payment#

Example: bank verification finishes and you return to Billing, but the subscription still shows past_due. Returning from the provider, a success parameter in the browser address, or a pending bank transaction does not by itself confirm payment. Compare the subscription state, the relevant invoice and the provider’s record of that same transaction. The return notice also directs you to the records below for the confirmed outcome. Establish the existing outcome before buying the plan again.

1. Match invoice number, period, amount and currency with your earlier note; make sure you are reading the right period.
2. Refresh Billing shortly, then check invoice status, payment date and subscription status separately.
3. If the provider confirms payment but records disagree, contact support with the same transaction reference. A blank paid date alone does not prove the bank received nothing.
4. Until the outcome is clear, avoid another payment method or subscription. Describe a pending bank transaction as pending in the support record.

Prepare a useful report when payment will not open#

A payment page that never opens, a card rejection on that page and an unchanged invoice after verification need different evidence. State the last stage you reached. “Pay now at 14:20, error before provider page” differs from “verification completed, invoice sent after return”. Have the owner or billing manager coordinate one case. The actual error text helps investigation; card details, bank access and session secrets are unnecessary.

1. Record the visible account name, invoice number, provider, time and time zone; include a safe transaction reference if available.
2. Describe browser, device, last screen and exact error. Explicitly say whether the earlier attempt’s outcome is known.
3. Redact card number, CVV, bank verification code, password, QR code and secret payment-link parameters from screenshots.
4. Continue the same case instead of starting attempts across many tabs before support advises another attempt. Separate a definite rejection from an ambiguous timeout.

Monthly addon coverage and renewal#

Addon payments are tracked separately from your main plan subscription. A new monthly order captures its capacity or feature; later catalog edits do not change that purchased effect. Read the payment method and renewal terms before continuing.

Dodo renews automatically each month; other methods prepay one month. Quantity adds capacity, not months. Addon expiry does not delete existing sites, servers or files.

Card or subscription authorization alone is not a paid period. Access becomes active when verified payment and subscription facts match. A paid parameter in a return URL does not grant access. If payment is completed but access is pending, check the same invoice and provider status before starting another payment.

Addon expiry preserves your main plan and independent manual rights. It does not delete existing servers, sites, users, keys or files. Usage above the reduced limit needs capacity before new resources or uploads can be added. Storage addon expiry does not trigger automatic removal of existing media.

Earlier purchases may have merged plan limits, addons and manual changes. Those rights are not automatically subtracted or added again; ambiguous records need support review. Keep existing subscription and ready-checkout terms separate from new orders.

For past-due payment, open the provider portal for the same subscription and pay the outstanding invoice or update its payment method. Do not purchase the same addon again. Successful payment and subscription reactivation may arrive as separate notifications; the panel verifies both. A zero-value card verification does not settle the debt. If the status stays unresolved, contact support with the invoice/order reference, never card details or a secret token.

Pausing stops access. A verified resume notification restores only previously paid remaining time, capped by provider dates; it does not create a new paid month. Scheduled cancellation keeps the current paid period. Conflicting notifications or unclear event order may require support review.