Skip to content
cartonium help

Checkout & payment troubleshooting

Use Operations → Checkout sessions and Operations → Payments to investigate checkout activity. Owners, Admins, and Staff can inspect records for their selected store. These views provide inspection and navigation, with no controls to charge, capture, refund, retry a payment, or run reconciliation.

Find the checkout

  1. Confirm the selected store and Sandbox or Live mode match the checkout you are investigating.
  2. Open Operations → Checkout sessions. Start with Status → Any, enter Customer email, and select Apply.
  3. Compare Started, Customer, and Total to the customer's report. There can be several sessions for the same customer.
  4. Select Inspect → on the matching row. Confirm Currency, totals, and Session id on the detail page.
  5. Check the Order section. Open the linked order number when present; linked checkout orders can open in Sales. Otherwise the page says No order created from this session yet.

Use Next page → for older results or Clear to return to the unfiltered first page. Could not load checkout sessions is a loading failure, not an empty result; refresh before drawing a conclusion. A missing result alone does not establish whether money moved.

Find payment attempts for a known session

Open Operations → Payments. Enter the Checkout session id, optionally choose Status and Kind, then select Apply. Use Inspect → to open the associated session. Clear resets the filters and pagination.

This list contains attempts linked to checkout sessions. It is not the full Sales payment ledger, and a session with no payment attempt will not appear here. For invoice payments, manual entries, or Sales refunds, use Recording payments & refunds.

Read the session and payment states separately

The session list's Payment column summarizes its newest attempt. Open the detail page and review all Payment attempts, including their Kind, amount, status, processor status, and any processor object ID shown.

  • Session OPEN or PENDING_PAYMENT: checkout is not yet confirmed. This status alone does not establish whether a payment succeeded.
  • Session CONFIRMED: check the linked order for the confirmed order outcome.
  • Attempt REQUIRES_PAYMENT_METHOD or REQUIRES_ACTION: payment is not recorded as complete. The customer may need to follow the current checkout's payment or verification instructions.
  • Attempt PROCESSING: payment is still in flight. Check its outcome before asking for another payment.
  • Attempt REQUIRES_CAPTURE: funds are authorized and awaiting capture; this is not a completed payment. These inspection pages cannot capture it.
  • Attempt SUCCEEDED: read its Kind and check the order outcome. A successful payment attempt and a confirmed order are separate records.
  • Attempt FAILED or CANCELLED: review the other attempts too; this row does not describe every attempt for the session.
  • Kind SETUP: this is payment-method setup, not a charge. A successful setup is not payment for an order.

Binding → yes does not mean paid. Likewise, an expired, abandoned, or cancelled session is not confirmation that a refund completed.

Payment succeeded but no order is shown

  1. Review every attempt and compare its amount, currency, and processor object ID with the reported payment.
  2. Check the Order section and Timeline, then refresh to read the latest recorded state.
  3. If a payment succeeded but the order is still missing, contact support with the details below. Keep the customer on a status recheck or support path; do not ask them to pay again while that payment's outcome is unresolved.

An explicit customer message that payment was already received can appear while the order is still finalizing. A generic checkout error does not establish the same result. Follow the current message rather than repeatedly submitting payment or creating a replacement payment record to make the statuses agree.

Timeline helps explain what was recorded. A checkout_session.refunded entry does not by itself confirm that money reached the customer. Check the actual refund outcome through the owning order or refund workflow, or ask support. Do not issue another refund solely because of that timeline entry.

If an attempt shows an account beside its processor object ID, use that account when correlating the payment. If it says processed on the cartonium platform account, contact support when the object cannot be found in your connected account. An absent account note is not proof of payment-account readiness or the payment's outcome.

Checkout is unavailable before payment

Ask an Owner or Admin to review the payment account under Settings → Checkout and use Refresh status where available. Follow Connect your Stripe account for account readiness, and its tax setup instructions when checkout reports a tax problem. Check Shipping for destination and rate setup. Payment-account verification alone does not establish that all checkout setup is ready.

Gather the details for support

Include the selected store and mode, Session id, Started time, amount and currency, session status, each relevant attempt's Kind/status and processor object ID, any displayed account note, and the linked order number or the missing-order message. Add the visible Timeline error and the customer's current checkout message. These details help support correlate the records without asking the customer to submit another payment.

Related