# My Card Was Declined' Shopify Support Scripts That Don't Sound Robotic > When a customer's card is declined, the wrong words can lose the sale forever. Here's a tactical guide to writing Shopify support scripts that recover the order and build trust, instead of sounding like a robot. Source: https://arbyn.app/blog/my-card-was-declined-shopify-support-scripts-that-don-t-sound-robotic Published: 2026-08-19 --- A failed payment is not a technical error. It is a moment of high-stakes commercial friction, and for many Shopify stores, it is a blind spot the size of a shipping container. Payment failures impact roughly one in five e-commerce orders, creating an estimated $47 billion in annual revenue leakage globally. More alarming is the rate of false declines, where legitimate transactions are incorrectly flagged as fraud. Research shows that for every dollar lost to actual fraud, store owners can lose far more to these false positives, with some analyses suggesting the cost of false declines is more than 13 times that of actual fraud losses. The default “card declined” message is a conversation-ender, a blunt instrument that often creates more problems than it solves. It leaves the customer confused, sometimes embarrassed, and likely to abandon the purchase altogether. For the store owner, it’s not just a single lost sale; it’s a wasted customer acquisition cost and the potential destruction of a customer’s entire lifetime value. Crafting a better card declined support script for Shopify is not about finding clever wording; it’s a strategic imperative for revenue recovery and brand preservation. The Anatomy of a Failed Transaction: Why "Do Not Honor" Is a Useless Message When a customer’s card is declined, the payment gateway receives a two-digit response code from the customer's issuing bank. This code is the technical reason for the failure. Shopify, like any other platform, often surfaces a simplified version of this code to the store owner and, in some checkout configurations, to the customer. The problem is that these codes are designed for banks, not for human beings trying to complete a purchase. A message like "05: Do Not Honor" is the most common and least helpful of all. It’s a black box, a generic refusal from the issuing bank with no specific reason given. The customer is told to contact their bank, a high-effort step that most will not take. They are far more likely to simply close the tab and buy from a competitor. This single, opaque message is responsible for a significant percentage of lost sales at the final step of the checkout funnel, a catastrophic loss after you have already paid to acquire the customer and guide them through your entire site. The damage extends far beyond a single abandoned cart. When a legitimate customer is declined, especially if it's a "false positive" from an overzealous fraud filter, the experience can feel like an insult. It creates a lasting negative association with your brand. Studies have shown that a significant percentage of customers who experience a false decline will not return to the store owner, with one report finding that 42% of consumers said they would never return to the business after a failed payment attempt. Some will even take to social media to complain about the poor checkout experience. Simply passing along the raw decline code abdicates responsibility for the customer experience at its most critical juncture. The customer doesn't see their bank as the problem; they see your store as the problem. They trusted you with their purchase, and your system rejected them without a clear explanation or a path to resolution. This erodes trust and makes it exponentially harder to win that customer back in the future. To craft an effective support script, you must first understand the landscape of these declines, which generally fall into two categories: soft declines and hard declines. A soft decline is a temporary failure, often due to issues like insufficient funds (Code 51), an exceeded credit limit (Code 65), or a network timeout (Code 91). These are often recoverable. A customer can transfer funds, wait a short period, or simply retry the transaction. A hard decline is a permanent failure, such as an invalid card number (Code 14), an expired card (Code 54), or a card reported as lost or stolen (Code 41/43). These cannot be resolved by retrying the same card. The only path forward is a different payment method. A generic "card declined" message treats both scenarios identically, offering no tailored guidance and squandering the opportunity to recover a salvageable soft decline. The table below breaks down some of the most common decline codes and illustrates why simply showing the customer the raw reason is a failing strategy. It creates a support ticket born of confusion, forcing your team to act as a translator for cryptic banking jargon. An effective support script pre-empts this confusion, translating the technical code into a human-readable diagnosis and a clear, actionable next step. It shifts the support interaction from a reactive explanation of a problem to a proactive partnership in finding a solution. This is the fundamental difference between a robotic response and a revenue-recovering conversation. Decline Code Technical Meaning Why It's a Bad Customer Message 05: Do Not Honor General decline from the customer's bank. Offers no information. This is the most common and least helpful code, forcing the customer to guess the problem. 51: Insufficient Funds The account lacks the funds to cover the purchase. Can be embarrassing for the customer and feels accusatory. A more delicate approach is needed. 14: Invalid Card Number The card number entered does not exist or has a typo. Helpful, but can be phrased more gently. "Invalid" sounds like a harsh judgment of the user's input. AVS Mismatch The billing address provided does not match the bank's records. Highly confusing for customers who know they entered their own address correctly. It requires explanation. 62: Invalid Service Code / Restricted The card cannot be used for this type of transaction (e.g., online). The customer has no idea what a "service code" is or why their card is "restricted" for a normal purchase. 63/97: Security Violation / Invalid CVV The CVV code is incorrect, or a security rule was triggered. "Security violation" is alarming language that can make a customer worry their card has been compromised. 54: Expired Card The card's expiration date has passed. This is a clear, hard decline, but the script should pivot immediately to requesting a new payment method. A Framework for Human-Sounding Decline Scripts Replacing a robotic response requires a structured approach that prioritizes empathy, clarity, and action. A good script is not a single block of text; it's a flexible framework that adapts to the specific reason for the decline while maintaining a consistent, helpful tone. The goal is to transform the customer's thought from "my payment was rejected" to "they're helping me fix this." This framework consists of four key parts: Acknowledge and Reassure, Diagnose and Clarify, Guide to a Solution, and Provide an Alternative. Each part serves a distinct psychological purpose, moving the conversation from a point of friction to a path of resolution. This approach is essential for any effective card declined support script for Shopify, whether delivered by a human agent or an automated system. The process begins by acknowledging the problem and reassuring the customer. The initial moments after a decline are critical. The customer may feel frustrated, confused, or even embarrassed. Your opening line must immediately defuse this tension. Avoid blunt, accusatory language. Instead of "Your card was declined," try a softer phrase like, "It looks like the payment didn't go through." This phrasing externalizes the problem to the payment itself, rather than pointing a finger at the customer or their card. Immediately follow this with a reassuring statement that frames this as a common and solvable issue. Something like, "This happens sometimes, and we can usually get it sorted out quickly." This simple combination acknowledges the problem without assigning blame and immediately positions your support team as an ally, not an obstacle. It's a subtle but powerful shift in tone that sets the stage for a cooperative, rather than confrontational, interaction. Next, you must diagnose the issue and clarify it for the customer. This is where you translate the cryptic bank code into a clear, understandable explanation. You must be careful not to simply parrot the technical jargon. If the decline is due to an AVS mismatch, don't say "There was an AVS mismatch." Instead, explain what that means in plain language: "It seems the billing ZIP code entered didn't quite match the one the bank has on file. Sometimes this happens if you've moved recently or have a PO box." For an "Insufficient Funds" decline, which requires the most delicacy, you can say, "The message we received from the bank suggests there may be an issue with the available balance for this transaction." For a generic "Do Not Honor," be honest about the lack of information but frame it as a protective measure: "The bank sent back a general decline message without a specific reason. This is often a security precaution on their end to protect your account." This step demystifies the process and gives the customer the context they need to understand the next steps. The framework concludes by guiding the customer to a solution and always providing an alternative. An explanation without a next step is useless. For each diagnosis, provide a clear, simple action the customer can take. For the AVS mismatch, suggest, "Could you please double-check the billing address and try again? Making sure the ZIP code matches the one on your card statement usually does the trick." For insufficient funds, offer a low-pressure path: "You might want to check the balance or try a different card if you have one handy." Crucially, always have a fallback plan. The ultimate goal is to complete the sale, not necessarily to force the original payment method to work. End the interaction by making it easy to switch gears: "If you'd prefer, we can also try processing the order with a different card, or I can send you a secure link to complete the payment via PayPal. Just let me know what works best for you!" This provides an escape hatch, ensuring that even if the original card issue can't be resolved, the sale isn't lost. Scripts for the Three Most Common Decline Scenarios Theory is useful, but practical, copy-and-pasteable scripts are what make the difference in a busy support queue. The following examples apply the four-part framework to the most frequent and frustrating decline reasons a Shopify store will encounter. These are designed to be starting points, ready to be adapted to your brand's specific voice. The key is how they reframe the problem. Instead of presenting a dead end, they open a new path forward. They assume the customer is acting in good faith and that the payment failure is a temporary hurdle, not a final verdict. This subtle shift in perspective is what separates a support interaction that loses a customer from one that builds loyalty. A well-designed card declined support script for Shopify is a tool for turning a moment of failure into an opportunity for exceptional service. The most ambiguous and frustrating scenario is the "05: Do Not Honor" decline. This is the most frustrating for both the customer and the support agent. Since the bank provides no specific reason, your script must manage this uncertainty with confidence and clarity. The wrong approach is to simply say, "Your bank declined it, please call them." This is technically correct but operationally useless. A better script acknowledges the ambiguity and provides a logical troubleshooting ladder. It starts with the simplest potential issues and works up to contacting the bank, giving the customer agency in the process. This prevents the customer from feeling helpless and shows that you are actively trying to solve the problem with them, even with limited information. It demonstrates a commitment to seeing the transaction through, which can be enough to keep the customer engaged. Scenario 1: Generic Decline (Code 05: Do Not Honor) * **Bad Script:** "Your card was declined with a 'Do Not Honor' error. You need to contact your bank." * **Good Script:** "It looks like the payment didn't go through on the first try. The message we received from your bank was a general one, which often happens as a security precaution. Before you go through the trouble of calling them, there are two quick things we can check. First, could you confirm the card number and expiration date were entered correctly? Sometimes a small typo can trigger this. Second, if you're using a card from outside the country, banks can sometimes flag the transaction. If neither of those seems to be the issue, giving your bank a quick call is the next best step. Alternatively, I'd be happy to try a different card or send you a PayPal invoice if that's easier for you." Another common issue is the Address Verification System (AVS) mismatch. This decline is particularly confusing for legitimate customers. They know they entered their own address correctly, so the error message feels like a system bug. It's critical that your script explains what AVS actually checks, typically just the numeric parts of the street address and the ZIP code, and why a mismatch can occur even with a valid address (e.g., a recent move, a typo in the numbers, or using a business address for a personal card). By explaining the mechanism, you validate the customer's experience and show that the error isn't their fault. The script should then guide them to check the specific numeric components of the address, which is a much more targeted and effective action than just telling them to "check the billing address." Scenario 2: AVS Mismatch * **Bad Script:** "AVS failed. The billing address is wrong." * **Good Script:** "It seems we've hit a small snag with the payment. The system that verifies addresses had trouble matching the billing information to what the bank has on file. This is usually just an issue with the numeric parts of the address. Could you please double-check that the street number and ZIP code exactly match what's on your card statement? Sometimes a recent move or a simple typo in the numbers can cause this. If it still gives you trouble, using a different payment method like PayPal can bypass this verification step entirely. Let me know how you'd like to proceed!" Handling the "51: Insufficient Funds" decline requires the most delicacy. Directly telling a customer they don't have enough money can be embarrassing and may cause them to abandon the purchase out of discomfort. The script must handle this with extreme tact. The goal is to convey the issue without making a direct statement about the customer's financial situation. Phrasing it as an issue with the "available balance for this specific transaction" is a softer, more professional approach. It leaves open the possibility of daily limits or other bank-side restrictions. The key is to quickly and smoothly pivot to alternative solutions, normalizing the situation and making it clear that you are focused on completing their order, not judging their bank balance. Offering an immediate, easy alternative like a different card or PayPal is crucial here. Scenario 3: Insufficient Funds (Code 51) * **Bad Script:** "You have insufficient funds. The payment was rejected." * **Good Script:** "It looks like the payment was not approved by the bank. The message suggests there might be an issue with the available balance for this transaction, which can sometimes be due to daily spending limits set by the bank. If you'd like, you could try a different card, or I can immediately send over a link to complete the purchase with PayPal. We can definitely get this sorted out for you." From Reactive Scripts to Proactive Recovery A great script is only one piece of the puzzle. While it can salvage a transaction that has already failed, a truly mature operation works to prevent that failure from happening in the first place or automates the recovery process. This means shifting from a purely reactive support model to a proactive payment optimization strategy. The data from your failed transactions is a goldmine. Analyzing your decline codes can reveal patterns. Are you seeing a high number of AVS mismatches? Your checkout form might be confusing, or you may be attracting a lot of customers who ship gifts to alternate addresses. Are you seeing a lot of "Do Not Honor" declines from international cards? Your payment processor might have overly aggressive fraud filters for cross-border transactions. This data allows you to address the root cause, rather than just treating the symptoms one support ticket at a time. One of the most powerful proactive strategies is intelligent retries. Not all declines are created equal. A "soft decline" like a temporary network error (Code 91) or a generic issuer decline (Code 05) can often be resolved by simply retrying the transaction a few moments later. Some payment gateways can be configured to do this automatically. This process is invisible to the customer and can recover a significant percentage of failed payments with zero manual intervention. Ecommpay, a payment platform, suggests that intelligent retry logic can recover between 15% and 30% of initially failed transactions. For a store losing thousands of dollars to payment failures, this automated recovery can have a material impact on the bottom line. It transforms a potential support ticket and lost sale into a successful order without anyone lifting a finger. Another critical layer is the customer communication that happens *after* they've abandoned the checkout. A failed payment is a common reason for cart abandonment. Instead of letting that be the end of the story, you can use automated email flows to re-engage these customers. An email sent an hour after a failed payment can be incredibly effective. It should lead with empathy, acknowledge the checkout trouble, and provide a direct, easy path to complete the purchase. This could be a link that reloads their cart with a prompt to try a different payment method. The messaging here should echo the principles of a good support script: be reassuring, helpful, and focused on a solution. For example: "Hi [Customer Name], we noticed you had some trouble checking out earlier. Technology can be tricky sometimes! Your cart is saved and waiting for you right here. If you'd like to try a different payment method, you can do so at the link below." Ultimately, the goal is to build a resilient payment ecosystem. This involves using a payment processor that provides rich data, employing tools that can automate recovery attempts, and designing communication workflows that treat a failed payment as the start of a recovery process, not the end of a sale. When you combine these proactive technical solutions with the empathetic, human-centric support scripts discussed earlier, you create a system that maximizes revenue capture while building customer trust. A declined card is no longer a crisis; it becomes a managed, and often resolved, operational event. This is the difference between a store that is at the mercy of its payment processor and one that is in control of its revenue. Implementing and Automating Your Scripts with an AI Agent Developing a library of effective, human-sounding scripts is a significant step, but their value is lost if they are not delivered consistently. In a human support team, this presents a major operational challenge. It requires extensive training, regular quality assurance checks, and constant reinforcement to prevent agents from reverting to robotic, unhelpful shorthand, especially under the pressure of a high-volume queue. An agent having a bad day can inadvertently cost the company thousands of dollars in lost sales by handling a few declined payment inquiries poorly. The tone, the empathy, the precise wording, all of it needs to be perfect, every single time. This level of consistency is incredibly difficult to maintain across a team of individuals, each with their own communication style and workload. This is where an AI support agent becomes a powerful operational lever. Unlike a human team, an AI agent can execute your carefully crafted scripts with perfect fidelity, 24/7, without ever getting tired or frustrated. You can program the exact logic: when decline code is "51," use the tactful "insufficient funds" script; when it's an "AVS mismatch," use the explanatory script that clarifies how the check works. The AI can instantly recognize the context of the customer's query, whether it's in a live chat or an email, and deploy the precise, pre-approved language that you have designed to be both empathetic and effective. This removes the variable of human error from your most sensitive customer interactions, ensuring every customer with a payment issue receives the same high-quality, on-brand experience. Furthermore, an AI agent can integrate the script directly with the necessary actions within your Shopify store. For example, after delivering the script for a declined payment, the AI can immediately offer to generate and send a new checkout link with a different payment option like PayPal already selected. For Arbyn, this is a core capability. The agent doesn't just talk; it does. It can be configured with your custom scripts, learning your brand's voice from past support conversations. When a customer messages your support email or live chat with a payment problem, Arbyn can diagnose the situation and respond using the exact non-robotic language you've defined. It turns a high-friction manual support task into an automated, revenue-recovering workflow. The implementation process is straightforward. You define the triggers (like keywords "declined," "payment failed," or specific decline codes if available) and map them to the corresponding scripts. You then define the follow-up actions, such as offering alternative payment links. The AI handles the execution, freeing up your human team to focus on more complex, high-judgment issues that require genuine human intervention. This hybrid approach, letting the AI handle the high-volume, scriptable conversations with perfect consistency, while humans handle the escalations and edge cases, creates a more efficient and resilient support operation. It ensures that a simple, solvable issue like a declined card is handled instantly and correctly, maximizing the chances of saving the sale and leaving the customer with a positive impression of your brand's helpfulness and professionalism. A declined payment is an inevitable part of e-commerce, but losing the customer is not. By moving away from the default, robotic error messages and embracing a more empathetic and strategic approach to communication, you can transform these moments of friction into opportunities to build trust. The scripts and frameworks outlined here provide a blueprint for that transformation. They are not just about choosing the right words; they are about adopting a customer-centric philosophy at the most critical point in the purchasing journey. Whether you implement them through your human support team or automate them with a tool built for the task, the principle remains the same: treat every declined card not as a lost cause, but as a conversation waiting to happen. For stores ready to automate this level of service, you can install Arbyn free from the Shopify App Store and configure your own custom decline scripts today. --- ## Pricing - **Arbyn Starter** - $0/month, permanently free. 150 conversations / month. Resets 1st of each month. - **Arbyn Growth** - $59/month flat. 500 conversations / month. Resets 1st of each month. Or $600/year (just under two months free, saves $108, 15% off). - **Arbyn Agent** - $99/month flat. Unlimited conversations. Or $990/year (two months free, saves $198, 17% off). - **There is no trial.** Billing starts immediately on any paid plan. The free Arbyn Starter plan is permanent. - The conversation cap is the only difference between plans. There is no feature gating. ## Channels Live today: **support email** and **on-site live chat**. That is the complete list. SMS, Instagram DMs, Facebook Messenger, WhatsApp and Voice are on the roadmap and are NOT live. Arbyn does not edit orders or change line items. Money-moving actions (cancel, refund, discount, gift card, reship, return) require the store owner's approval, and then Arbyn performs them. Running them fully autonomously is a beta authorization and is in development. Shipping address changes are already autonomous. ## What Arbyn does on a Shopify order - **Change the shipping address**: Live. Arbyn does this on its own. Arbyn updates the shipping address on the Shopify order itself, inside the conversation, and writes the change to the order timeline. - **Cancel an order**: Live. You approve it, then Arbyn cancels the order. Anything that moves money waits for the store owner's approval. That is a deliberate control, not a missing feature. Once you approve, Arbyn fires Shopify's order cancellation itself and confirms it to the customer. - **Issue a refund**: Live. You approve it, then Arbyn issues the refund. Arbyn prepares the refund against the original payment method and sends it to you. On approval it files the refund in Shopify. You can cap the value it is allowed to prepare, per channel. - **Apply a discount**: Live. Arbyn creates a real Shopify discount and applies it to the cart, handing the shopper a checkout with the code already on it. It can also issue a discount code on an order once you approve it. - **Send a gift card, or reship an order**: Live. You approve it, then Arbyn does it. Arbyn creates the gift card, or raises the replacement order, in Shopify once you approve. - **Start a return**: Live. You approve it, then Arbyn opens the return. Arbyn opens the return in Shopify on your approval. - **Look up a gift card or store-credit balance**: Live. Arbyn does this on its own. "Do I have store credit left?" is a question most support tools answer with a human. Arbyn reads the balance itself, for a verified customer or from the code they give you, and reports the masked card, the balance and the expiry. If there is no card, it says so rather than guessing. - **Handle a subscription question**: Live. You choose what it does. Arbyn knows which of your products are sold as a subscription, shows that on the product card in the conversation, and sends a subscriber to their subscription management page to pause, skip or cancel. It answers how your subscriptions work from your own knowledge, but it does not read an individual customer's contract, so it will not state their renewal date or status. Most cancels are a customer with product piling up, and the fix is getting them to the page where they can slow the cadence down. Reading the contract itself is on the roadmap. - **Answer support email and live chat**: Live. Arbyn reads every inbound support email and every chat, works out the intent, pulls the live Shopify context, and replies in your brand voice. Money-moving actions (cancel, refund, discount, gift card, reship, return) require the store owner's approval, and then Arbyn performs them. Running them fully autonomously is a beta authorization and is in development. Shipping address changes are already autonomous.