High-Ticket Payment Questions

What this category covers

This category covers per-transaction caps, velocity limits, reserves, and the underwriting behind accepting very large invoices. The answers are written to give you the structure of the decision - what has to be true, who decides it, and what to get in writing - rather than a single number that stops being accurate the moment your volume or card mix changes.

Where an answer depends on your own account, it says so and points at the statement line that would tell you. A page cannot know your effective rate, and any page that claims to is guessing.

Why it matters operationally

A declined six-figure payment costs you more in customer confidence than it does in fees.

The cost of getting this wrong is rarely dramatic. It is a few basis points on every transaction, every month, which is exactly why it goes unexamined for years.

Where operators go wrong

• Discovering a per-transaction cap while a customer waits on the phone.
• Splitting an invoice to evade a limit, which processors identify quickly.

1 question in this category

• Why did our large customer payment decline?

  Most often because of a per-transaction cap or velocity limit on your own merchant account rather than anything on the customer's card. These limits are set during underwriting based on your financials, average ticket and processing history, and they do not grow with your business unless somebody asks. The decline reason is frequently not passed through to whoever ran the payment, which is why it looks like a customer problem.

  Updated September 30, 2026

This category is still being built out. We keep it linked from the questions hub, but hold it back from search listings until it carries at least 3 published answers — a page with nothing to list is not worth anybody's click.

What to read next

/high-ticket-payment-processing covers limits, reserves and when a card is the wrong rail entirely.