Before Orders & Inventory commits stock, creates an invoice, or takes a payment, Rhythm checks the order. Most orders pass these checks without anyone noticing, but some checks stop the order at the final step. This article explains what Rhythm checks and why an order can be refused later than you expect.
Why a Price You Saw Can Still Be Refused
Some checks run only when you submit the order for processing, not when you preview or price it on screen. A buyer or staff member can see a total, an applied coupon, and a payment screen, then have the order refused at the final step. That is expected because the preview shows what the order would cost, but it does not guarantee Rhythm will accept the order.
One check now happens earlier than it used to. A bundled product with SKU-based inventory tracking used to save without warning, then fail during order processing with a generic error. Rhythm now blocks that product on the product screen and tells you to choose another product, instead of waiting for an order that uses it to fail.
The Checks, In the Order They Matter
| Check | What triggers it | What the buyer or staff member sees |
|---|---|---|
| Expiration | The order has an expiration date, and that date has passed. Rhythm compares the date using server time instead of a specific time zone, so the order can expire a little earlier or later than you expect. | “This order has expired. You can no longer process it.” This message appears only after someone submits the order, not while they preview it. |
| Duplicate submission | An order with the same buyer, product lines, and quantities was processed within the last sixty seconds. Rhythm still treats it as a duplicate even when the price, coupon, payment method, or shipping choice is different. | “Duplicate order detected.” You can submit the same order successfully after the minute has passed. |
| Acting for the bill-to party | The buyer or staff member is not allowed to place an order billed to the contact or organization named as the bill-to party. | Rhythm refuses the order before pricing finishes. |
| Batch missing or closed | The order has no batch assigned, or its batch is not open for new transactions. | A message names the batch and its current status. |
| Store credit as a payment type | The order names “store credit” directly as the way it will be paid. | “Store credit cannot be supplied as a payment type; it is applied automatically from available credits.” |
| Missing exchange rate | The order needs a currency conversion, but the exchange rate is not configured or was deleted after the product was set up. | An error appears when someone submits the order. Rhythm does not block this earlier on the product screen because a rate could still be removed later, so complete multi-currency setup before you rely on it. |
| Finance validation | The transaction rules in your finance records find a problem with the order. | A message from those rules appears as the order error. |
If a currency conversion failure shows a generic or undefined error, the exchange-rate lookup itself usually failed, not order processing. Rhythm shows a more specific message when it can, which helps you tell those two issues apart.
Why “the Same Order” Can Mean More Than You Expect
The duplicate-submission check looks only at the buyer, product lines, and quantities on the order. It does not compare the price, coupon, payment method, or shipping choice. If two submissions have the same products but different payment methods, and they happen less than a minute apart, Rhythm treats the second submission as a duplicate and refuses it. If you need to correct an order you just submitted, wait for the one-minute window to pass before submitting it again, or edit the accepted order instead of submitting a new one.
If a duplicate-order refusal keeps appearing well outside that window, especially after an earlier payment on the same person’s order was declined, the cause may be a leftover draft order from the earlier attempt rather than the sixty-second check. Contact Support if a retry after the window still fails this way.
Who Can Buy on Whose Behalf
An order names a bill-to party, which is the contact or organization that will owe for it. Before Orders & Inventory prices or accepts the order, Rhythm checks that the person placing the order can act for that bill-to party. This check only looks at the bill-to party. It does not check the ship-to party or a line sent to a different recipient, so an order can ship to, or be personalized for, someone the buyer could not have billed directly.
This also means the person shown as the order’s recipient is not necessarily the person who placed it. Do not expect the recipient’s own profile to list them as having placed the order, because placing and receiving are tracked separately.
Paying at Checkout, or Paying Later
A member buying in the Portal is normally required to pay at checkout. Order type settings control whether payment can be deferred through options such as paying later or billing an organization. When those settings allow deferred payment, Rhythm accepts and delivers an unpaid order right away, before payment is collected.
Rhythm enforces the payment requirement only when the order is submitted. While the member previews the order, Rhythm does not show the price or missing-payment condition as an error. The member can reach checkout without seeing a payment-required warning until they try to complete the purchase. These payment controls are set separately in each app, event, or process’s checkout configuration, not through one account-wide Portal rule. Check the specific process’s settings instead of looking for a single global switch.
A billing address marked as required on the order form is required no matter which payment method is chosen, including Pay Later. An order used to be able to complete without one when Pay Later was selected, but that gap is closed. When you save a credit or debit card during order processing, Rhythm also requires a full address on the card and blocks saving without one.
Choosing an installment plan at checkout does not by itself guarantee that Rhythm collects the first installment right away. If the buyer also selects a pay-later option, the initial payment can be deferred like the rest of the order, and only the later installment charge may go through as scheduled. A configured card-processing fee can also be missing from a pay-later order’s payment. This is a known issue, so do not assume the fee setting is misconfigured when the fee is absent only on orders that were paid later.
The option to split payment across two methods appears only when the order has more than one payable line. A single item cannot be split across two payment methods, though adding a donation as a second line is enough to make the option available.
If the second payment method's card fields stay blank and will not accept input during a split payment in the Portal, check the first payment method before assuming something is broken. The second step does not become active until the first payment method has been finalized with Save Card.
Store credit is never a payment method that a buyer can choose directly in the Portal or the Console. Rhythm applies it automatically to the amount owed. Whether credit applies automatically can also depend on how the order originated, or on account-specific configuration beyond the order type’s own payment settings. If credit applies in one flow but not another, the difference may be in how each order was created rather than in a setting you can see and change. See How Orders Are Invoiced and Paid for how open credits are drawn on and combined with other payment methods.
An unpaid order allowed by these settings is normally announced for fulfillment right away, before payment is collected. For a document or digital product’s entitlement specifically, the entitlement has been seen to be granted automatically only when payment is taken during processing. If payment on a Pay Later order for a document product is collected afterward, the entitlement may not appear on its own. Check the contact’s entitlements once payment is received, and add the entitlement by hand if it is missing.
A Pay Later order with more than one line item has, in the past, left a second line, such as a companion dues line, in Open status even after the invoice was fully paid. If you see an older order stuck this way after payment, that is likely the cause. This has since been corrected for new orders.
What to Do When an Order Is Refused
Most refusal messages tell you exactly what to fix. You may need to submit the order again after the duplicate window passes, choose a different batch, remove a directly named store-credit payment, or check the order’s expiration date. If the message points to a finance validation problem, or you cannot tell which check refused the order, contact Support with the exact message text and the approximate time the order was submitted.
If the process-order button spins indefinitely instead of failing with a message, check for a required selection you have not made yet, such as a missing option or field earlier in the order. An incomplete order can look like a stuck request rather than a validation failure. If a pending-order banner will not go away for a member trying to register at a member price, check whether an earlier order for that member still has a balance due. Paying that balance should clear the banner. If a split-payment attempt fails with a gateway authorization error, check whether the same member has more than one open or in-progress order. Deleting the extra one can let the remaining authorization complete or be retried.
A card-gateway error can also be misleading. A payment attempted with one card brand has been seen to return a security-validation error that names a different brand, even though the payment actually went through. Check whether the payment posted before treating a security error as a failed charge.
If a checkout problem affects only one Portal user, the cause is often on their side rather than in Rhythm. Their VPN, browser extensions, intermittent connection, or stale cached browser data can all cause an order failure that no one else can reproduce. Clearing the browser cache is a reasonable first step, but it does not resolve every case. If that does not help, try an incognito or private window and, if possible, a different network. Backend order-processing failures that do not seem tied to a particular product can sometimes be traced to the user’s own network or VPN as well. If an order fails for one person but processes normally when you or the customer try again from a different network, that points to the network rather than the order itself. If a checkout failure seems tied to one specific product while other products in the same store work fine, and that product was cloned from another, try recreating the clone. A one-off problem with a copied product record is a common explanation in that situation.