When a customer’s card is declined at checkout, the decision almost always comes from one of two places: the customer’s card issuer (their bank) refused the charge, or your payment processor’s fraud screening blocked it before it ever reached the bank. A third, less common cause is a technical error in how the payment was sent. Your job as a seller is to work out which of these happened, tell the customer the right next step, and fix anything on your side.
In practice, the fastest fix for most declines is simple: ask the customer to check the card details they typed, then call the number on the back of their card or pay with a different card or method such as PayPal. If you see the same decline across many customers, or the payment shows as blocked rather than declined, the problem is more likely in your own fraud settings, and that is something you can change.
Issuer declines vs. your processor’s fraud blocks
Stripe’s documentation splits failed payments into three groups: issuer declines, blocked payments, and invalid API calls. An issuer decline means the charge reached the customer’s bank and the bank said no. Stripe explains that issuers’ automated systems weigh signals such as spending habits, account balance, and card data including the expiration date, address information and CVC.
A blocked payment is different. Stripe Radar, the fraud tool built into Stripe, blocks payments it rates as high risk or that break custom rules you set. When Radar blocks a payment, Stripe does not ask the issuer for authorization at all. Stripe notes that for some cards the customer may still see a temporary authorization on their statement, but no money was taken and the issuer typically removes it within a few days.
In the Stripe Dashboard, open the failed payment and look at its outcome. An outcome type of issuer_declined means the bank refused it. A type of blocked, often with a seller message such as “Stripe blocked this charge as too risky,” means your own fraud screening stopped it. That one distinction tells you whether the fix lives with the customer’s bank or in your settings.
The decline codes you will see most often
Stripe attaches a decline code to every failed card payment. These are the ones sellers ask about most, with Stripe’s own descriptions and next steps:
generic_decline: the card was declined for an unknown reason, or Radar or Adaptive Acceptance blocked the payment. The customer needs to contact their card issuer. Stripe also notes that card issuers categorize most declines as generic, so this is the code you will see most.
do_not_honor: the card was declined for an unknown reason. Again, the customer needs to contact their card issuer. Stripe suggests checking whether CVC or address (AVS) checks failed, because that associated data can hint at why a generic or do_not_honor decline happened.
insufficient_funds: the card does not have enough funds or credit for the purchase. The customer needs to use another payment method. card_velocity_exceeded is related: the customer has exceeded the balance, credit limit or transaction amount limit on the card, and needs to contact their issuer.
incorrect_cvc and incorrect_zip: the security code or billing postal code was wrong. The customer should retry with the correct details. expired_card: the card has expired and the customer needs to use another card.
authentication_required: the transaction needed authentication such as 3D Secure. When you use Stripe’s own checkout pages, this soft decline usually triggers an authentication step so the customer can try again. If the issuer returns this code even after successful authentication, Stripe says the customer needs to contact their card issuer.
fraudulent, lost_card, stolen_card and merchant_blacklist are special. Stripe’s guidance is not to share these specific reasons with the customer and to present them the same way as a generic decline.
Why a card is declined when the customer has money
This is the most common complaint, and it makes sense once you know what the issuer is checking. A balance is only one input. Stripe notes that issuers may decline payments they suspect are fraudulent, which can be triggered by large purchases or a burst of transactions in a short time. Many cards also have daily or per-transaction limits, which show up as card_velocity_exceeded.
Card restrictions matter too. Stripe points out that FSA and HSA cards are often limited to certain kinds of businesses, and that some issuers do not allow purchases from certain countries or outside their own. Other codes such as card_not_supported and currency_not_supported mean the card cannot be used for that type of purchase or currency. In all of these cases, only the cardholder can get the restriction lifted by calling their bank.
International cards, 3D Secure and CVC/AVS mismatches
Cross-border payments decline more often. Stripe says that customers using cards issued in a different country from where your Stripe account is registered might see an increased rate of declines, and that the fix is usually for the customer to contact their issuer and authorize the charge. Stripe also notes that a card from one country used from an IP address in another can be a legitimate decline for possible unauthorized use, though travelers are a common exception.
3D Secure adds a verification step, such as a code in the customer’s banking app. In Europe and other regions with Strong Customer Authentication rules, issuers can require it. If the customer closes the pop-up, does not get the code, or fails the check, the payment fails. Ask them to try again with their banking app ready, or to call their bank if the prompt never appears.
CVC and postal code (AVS) checks are evaluated by the issuer, and Stripe’s Radar documentation notes that an issuer may still approve a payment that fails these checks. However, if you have enabled Radar rules that block payments failing CVC or postal code verification, your own settings can stop a payment the bank would have approved. A customer who recently moved and still has an old billing postal code on file is a classic case.
What you can see, and what you cannot
On Stripe you can see the decline code, the outcome type (issuer_declined, blocked or invalid), a seller message, the Radar risk level, and, when the network sends them, the network decline code and network advice code. Stripe also returns an advice code: do_not_try_again, try_again_later or confirm_card_data, which tells you whether a retry makes sense.
What you cannot see is the bank’s internal reasoning. Stripe states plainly that, for privacy and security reasons, card issuers discuss the specifics of a decline only with their cardholders. Square says the same from its side: when a card is declined, Square is not informed of the exact reason and recommends the customer contact their card-issuing bank. So do not promise a customer that you can “find out what went wrong” on your end.
What to tell the customer
Keep the message calm, short and free of blame. Something like: “Your bank declined this payment. That usually happens for security reasons and is easy to fix. Please double-check the card number, expiry date, CVC and billing postal code, then try again. If it still fails, call the number on the back of your card and ask them to approve a payment to us, or pay with another card or PayPal.”
Do not ask the customer to retry the same card over and over. Stripe warns that card networks limit how many times a single charge can be reattempted and that issuers may treat excessive retries as potential fraud, which can increase declines for legitimate charges. If the advice code is do_not_try_again, the customer should switch cards or talk to their bank first.
For declines Stripe marks as fraudulent, lost_card, stolen_card or merchant_blacklist, use the same neutral wording as any other decline. Never tell a customer their card was flagged as stolen.
What to check in your own dashboard
Start with the failed payment itself. Is it an issuer decline or a block? Did CVC or postal code checks fail? Was 3D Secure attempted, and did it complete? These answers come straight from the payment details page.
Next, look for a pattern. One decline from one customer is normal. Many declines in a short window, especially across different banks, points to something on your side: a new Radar rule, a currency your account does not support for that card, or an integration change. Stripe suggests tracking your decline rate over time and analyzing unique declines while excluding failed retries, so a single customer hammering the button does not skew the picture. If every payment is failing on Square, check Square’s status page and contact Square support.
Finally, confirm your checkout collects the CVC and postal code. Stripe recommends collecting both to reduce fraud-related declines and notes that 3D Secure can lower decline rates in countries that support it.
Adjusting fraud rules without opening the door to fraud
If a Radar rule you wrote blocked a customer you know is genuine, Stripe lets you open the payment and choose Add to allow list. This does not retry the payment; it stops your other rules from blocking future payments that match that list entry. The customer still needs to pay again.
For broader changes, follow Stripe’s own cautions. Test any rule against past payments before turning it on. Prefer a review rule over a block rule when you are unsure. Keep allow rules narrow, because they override Stripe’s default rules and every other rule. Stripe even gives the example of a block rule on all non-US cards being too broad, and recommends combining it with a risk level instead. Loosening rules can raise disputes, so change one thing at a time and watch the results.
Where OneSol fits in
If you sell through a OneSol storefront or form, payments go through your own connected Stripe, PayPal, Razorpay or Square account, and OneSol takes no cut. That also means OneSol does not approve or decline cards: the customer’s bank and your payment provider make that decision. Check the payment in your provider’s dashboard using the steps above, and offering a second payment option such as PayPal alongside cards gives customers an easy way to complete the purchase when one method fails.