A customer tries to pay, the card is refused, and the order is gone. On a research-peptide storefront this happens more than it does elsewhere — and founders usually treat it as one problem when it's actually four, with four different fixes.
Diagnosing which one you're hitting is most of the work.
- Declines come from four sources: the issuing bank, your processor's risk rules, the acquirer's category restrictions, or plain technical failure. They look identical to the customer.
- Response codes tell you which. Get them out of your gateway before theorising.
- A rising decline rate frequently precedes a processor review rather than following one. Treat a sharp increase as an early warning.
- The single cheapest fix is a recognisable billing descriptor — it reduces both declines and disputes.
- If the acquirer is restricting the category, no amount of checkout optimization helps. That's an underwriting problem.
The four causes
1. Issuer declines
The customer's own bank refuses the transaction. This is the most common cause and the one you control least.
Issuing banks run their own fraud models. A transaction can be declined for insufficient funds, an unusual merchant category, a card-not-present transaction that doesn't match the customer's pattern, an international merchant, a mismatched billing address, or simply an opaque internal risk score.
You cannot change a bank's model. You can reduce how suspicious your transaction looks:
- A recognisable billing descriptor. If it says something unrelated to what the customer thinks they bought, both declines and disputes rise.
- Accurate AVS and CVV data collection. Address mismatches trigger declines that clean data avoids.
- A checkout that doesn't look improvised. Poorly assembled checkouts trip fraud heuristics.
- Sensible order sizing. Unusually large first orders decline more often.
2. Processor risk rules
Your own processor blocks the transaction before it reaches the issuer, based on velocity limits, ticket-size ceilings, geographic restrictions, or fraud scoring.
These are usually configurable — but they're set the way they are because of your risk profile. Loosening them is a conversation with your processor, not a setting you should quietly change. And if they're declining a lot of your volume, that itself tells you something about how they view the account.
3. Acquirer category restrictions
The account isn't underwritten for what you're actually selling.
This is the serious one. If a mainstream aggregator is progressively declining your transactions, it frequently means their systems have begun classifying the business correctly — and a full risk review may be underway. Declines can be the first visible symptom of a process that ends in a freeze.
4. Technical and data failures
Unglamorous and genuinely common: expired cards, mistyped numbers, gateway timeouts, misconfigured 3-D Secure, currency mismatches, a checkout that breaks on mobile Safari.
These are entirely fixable and often account for a surprising share of "declines" that were never risk decisions at all.
Diagnosing which one you have
Stop guessing and get the response codes from your gateway. Every decline carries one, and they cluster:
| What you see | Likely cause | What to do |
|---|---|---|
| Scattered declines across many issuers, no pattern | Issuer-side risk models | Improve descriptor, AVS/CVV data, checkout quality |
| Declines cluster on large orders or repeat velocity | Your processor's risk rules | Talk to your processor about limits |
| Decline rate rising steadily over weeks on an aggregator | Category restriction / review underway | Move to proper underwriting, urgently |
| Declines on specific cards, browsers, or amounts | Technical / configuration | Fix the gateway and checkout |
Two useful habits: track decline rate as a weekly metric rather than noticing it anecdotally, and segment by issuer and order size. A rate that's flat and slightly elevated is a cost of doing business. A rate that's climbing is a signal.
Reading the response codes
Exact codes vary by gateway, but they fall into a small number of families, and the family tells you almost everything about what to do next.
| Response family | What it usually means | Retryable? | Your move |
|---|---|---|---|
| Do not honor / generic decline | Issuer risk model said no, without detail. The most common and least informative. | Sometimes, later | Descriptor, AVS/CVV, checkout quality |
| Insufficient funds | Exactly that | Yes | Retry on a schedule; offer an alternate method |
| Suspected fraud / pickup card | Issuer flagged the transaction or the card | No | Don't retry — repeated attempts worsen your profile |
| Invalid data — number, expiry, CVV, ZIP | Entry or configuration error | Yes, after correction | Fix checkout validation and field mapping |
| Restricted card / not permitted | Card type or category blocked | No | Offer another method |
| Exceeds limit / velocity | Per-transaction or cumulative cap hit — often your processor's, not the issuer's | No | Talk to your processor about your limits |
| Merchant category blocked | Acquirer or issuer refuses your MCC | No | Structural — you need proper underwriting |
Two things founders get wrong here. Hard declines should never be retried — repeatedly attempting a card the issuer flagged as fraud makes your merchant profile look worse and can trigger review on its own. And "do not honor" is not a diagnosis. It's the issuer declining to explain. If most of your declines are generic, the answer is almost always in the descriptor, the data quality, or the category — not in the checkout.
Cross-border declines
If you sell internationally, expect a materially higher decline rate on foreign-issued cards, and don't mistake it for a category problem.
Issuers apply stricter risk models to cross-border transactions, AVS frequently doesn't work outside the US in any meaningful way, and currency conversion adds another failure point. On top of that, European transactions generally require Strong Customer Authentication — if your checkout doesn't implement 3-D Secure properly, those transactions fail regardless of anything else you've done.
Segment your decline data by issuing country before drawing conclusions. A 20% decline rate that's actually 8% domestic and 45% international is a very different problem from a flat 20%.
What actually reduces declines
Fix the billing descriptor first. It's the cheapest, highest-leverage change available. It should clearly name the brand the customer believes they bought from. This reduces issuer declines and "I don't recognise this charge" disputes — and your dispute ratio is what decides your reserve terms.
Collect and pass complete data. Full billing address, CVV, correct currency. Incomplete data raises risk scores at every step in the chain.
Set clear expectations at checkout. Tell customers what the charge will appear as. Confirm the order by email immediately. Provide tracking. Most "declines" that turn into support tickets are actually confusion.
Offer a fallback path. Some orders will not go through on card regardless of what you do. An inquiry or invoice option recovers revenue that would otherwise be lost entirely — see the inquiry-based ordering model. For higher-value orders, many buyers in this category prefer invoicing anyway.
Get properly underwritten. If the underlying issue is that your account isn't approved for what you sell, everything above is optimization around a structural problem. A high-risk merchant account with a processor that underwrites research peptides deliberately removes the category-restriction cause entirely.
The connection to freezes
Declines, disputes and freezes are the same story at different stages.
High decline rates often indicate your transactions look risky to the payments chain. High dispute rates confirm it. Sustained high ratios in either trigger review — and for a research-peptide account on a mainstream aggregator, review tends to end in a category decision rather than a warning.
So the work that reduces declines is largely the same work that protects the account: accurate descriptors, clean data, fast support, tracked delivery, honest product pages, and a refund policy you follow. A refund costs you one order. A chargeback costs you the order, a fee, and a mark on the ratio that decides your reserve — and enough of them cost you the account.
The takeaway
Peptide payment declines aren't one problem. They're four, and the fix depends entirely on which one you're actually experiencing.
Pull the response codes. If it's issuer-side, fix your descriptor and your data. If it's your processor's rules, have the conversation. If it's technical, fix the gateway. And if the decline rate is climbing steadily on a mainstream aggregator, treat that as the early warning it usually is — and get underwritten properly before the review completes rather than after.
Who wrote this. Sell Peptides Online is the peptide practice of Axesris, a US web and SEO company that has built and shipped seven peptide brands — four of them wholesale operations. Everything here comes out of builds we actually ran, not a keyword list. Every person who touches client work is in the United States.