Skip to main content

Send card details with your Stripe Link payments

Stop Stripe Link payments arriving without card details, so we can match your alerts to the transaction that caused them.

Written by Theodore

Link is a Stripe payment method that lets customers pay with saved payment details. When Link stores those details as a token with no card connected to the payment, Stripe passes the payment to Chargeback.io without usable card details. We can't match that payment to the customer's card, so we can't connect it to any alert we receive later.

This article shows you three ways to fix that, and how to tell which one fits your setup.

Who this article applies to

Merchants connecting Stripe to a business account on Chargeback.io. You make these changes in your Stripe Dashboard or in your own checkout code, not in Chargeback.io.

It does not cover:

  • other payment processors

  • payments already processed before you make the change

  • other tokenized wallets, such as Apple Pay, Google Pay, and Shop Pay. Those hide card details too, and they need a different approach. See Find tokenized transactions in your payment processor. Fixing Link does not fix those.

Why card details matter

Card details are how we match an alert to the payment that caused it. When a payment arrives without them, any alert tied to that payment can't be matched to it. The alert lands in Attention status, it won't auto-refund, and the chargeback goes through.

Check whether this affects you

  1. In the Stripe Dashboard, open a recent payment made with Link.

  2. Look at the payment method on the charge.

    • A card brand and last four digits: card details are reaching us. Nothing to do.

    • A Link reference and no card: this article applies to you.

  3. In Chargeback.io, open your alerts in Attention status. Alerts we couldn't match to a transaction collect there.

Link without a card:

example of a Stripe transaction with Link enabled and a card

Link with a card:

Choose your fix

Option

Link stays at checkout

Needs a developer

Choose it when

A. Disable Link in your payment configuration

No

No

You use Stripe-hosted checkout, or you are willing to drop Link entirely.

B. Keep Link, process it as a card

Yes

Yes

You build your own checkout, using Checkout Sessions, Payment Elements, or SetupIntents.

C. Ask Stripe to enable Wallet Mode in Link

Yes

No

You would rather not touch code, and you are prepared to push Stripe support.

Note. Options A and B do the same thing under the hood: they tell Stripe to process the payment as a card. What differs is where you set it, and whether Link stays visible to your customers.

Before you start

  • Admin access to your Stripe Dashboard, to change payment method settings.

  • The list of payment configurations your account uses. A payment configuration controls which payment methods appear at checkout. Most accounts use only the Default configuration, but you may have more if you or your team created extra ones.

  • How your checkout is built. If your developers create Checkout Sessions or SetupIntents through the Stripe API, or use Payment Elements, your code can override the Dashboard. Start with Option B. Ask your developers if you are not sure.

Option A. Disable Link in your payment configuration

Before you do this. On an embedded or custom checkout, disabling Link removes Link as a payment option for your customers. If you need to keep Link available, use Option B instead.

Step 1. Find the payment configurations you use

  1. Go to Payment methods settings in the Stripe Dashboard.

  2. Review the list of payment configurations. If you have not created any extra ones, Default is the only configuration you need to check.

  3. Hover over the information icon next to a configuration name to see where that configuration is used.

  4. If you have enabled the Customer Portal, open Customer Portal settings and check which payment configuration it uses. Add that configuration to your list.

GIF showing how to disable Stripe Link in the Stripe dashboard

Step 2. Disable Link in each configuration

Repeat these steps for every payment configuration you found in Step 1.

  1. Open the payment configuration.

  2. Open Link.

  3. Click Disable in the side panel that opens.

  4. Follow the steps Stripe shows to confirm the change.

Option B. Keep Link and process it as a card

This one is a developer change. Stripe still offers Link at checkout, but processes the payment as a card, so the card details reach us. Check all three places below, because any one of them can keep sending link.

Server side: Checkout Sessions and SetupIntents

  • payment_method_types: do not pass link. card on its own is enough, and Link stays available to your customers.

  • payment_method_configuration: if you pass a configuration ID here, that configuration is what applies, not the Default in your Dashboard. Any Dashboard change has to be made in that configuration.

// Checkout Session - the same two parameters apply to SetupIntent
await stripe.checkout.sessions.create({
  payment_method_types: ['card'], // do not include 'link'
  // payment_method_configuration: 'pmc_...'  <- if you pass this, it
  // overrides the Default configuration in your Dashboard
  ...
});

Client side: Payment Elements

The Stripe components take their own configuration, and it behaves the same way as the server-side parameter.

<Elements
  stripe={stripePromise}
  options={{
    paymentMethodTypes: ['card'], // do not pass 'link' here
  }}
/>

What success looks like. After this change, a Link payment records both card and Link details on the charge in Stripe. That is what to look for when you verify.

Option C. Ask Stripe to enable Wallet Mode in Link

Wallet Mode makes Link behave as a wallet sitting on top of a card, so the card details travel with the payment. Link stays at your checkout and you change no code.

  1. Contact Stripe Support.

  2. Send this message:

    Can you please enable Wallet Mode in Link on my account?

  3. If the agent says no such configuration exists, ask to escalate to a team member who knows the feature.

Heads up. Front-line Stripe agents are often unfamiliar with this setting and will tell you it is not available. If escalation stalls, use Option A or Option B. Neither depends on Stripe support.

Existing customers and saved payment methods

Read this if you bill subscriptions. Your change only applies to payment methods saved after you make it. Payment methods already saved through Link stay exactly as they are, with no card details.

Every renewal on one of those keeps arriving without card details, and alerts for those payments still cannot be matched.

On a subscription business that means most of your existing customers stay uncovered until their payment method is replaced. The fix on its own changes nothing for them.

To close that gap, get affected customers to update their payment method. Re-attaching a payment method is enough, even if it is the same card:

  • Send them to your Customer Portal, or your own update-payment page, and ask them to re-enter their card.

  • Start with the customers who cost you most: repeat disputers first, then your highest-value subscriptions.

  • New customers are covered from the moment you make the change, so this list only shrinks.

Verify the fix

  1. Wait a few minutes. Dashboard changes take time to propagate, so a payment made right after you save can still behave the old way.

  2. Make a test payment through Link, or wait for the first real one.

  3. Open that charge in Stripe. You should see a card brand and the last four digits. With Option B you see the Link reference alongside the card.

  4. Over the next few weeks, check that fewer new alerts land in Attention status.

Limits

Not retroactive. These changes apply only to new payments. Existing transactions are not updated. Payments already processed through Link will still show without card details, and alerts on them still cannot be matched.

  • Dashboard changes can take a few minutes to propagate before they take effect.

  • Each payment configuration is separate. Disabling Link in one does not disable it in the others.

  • Your code wins over your Dashboard. If your integration passes payment_method_types or payment_method_configuration, those decide what happens, whatever the Dashboard shows.

Troubleshooting

Link does not appear in the payment configuration

Link is already disabled there. No action is needed for that configuration.

You are not sure which configuration is in use

Hover the information icon next to each configuration name in Payment methods settings. The tooltip states where that configuration applies.

Check your Customer Portal settings as well, because the portal can use a different configuration than your checkout. And if your code passes a payment_method_configuration ID, that is the one in use. Ask your developers which ID they send.

Link still appears at checkout after you disable it

Wait a few minutes and check again. Dashboard changes take time to propagate.

If Link still appears, confirm you disabled it in the configuration your checkout actually uses, not only in Default.

Link disappeared from checkout and you wanted to keep it

Re-enable Link in the payment configuration and use Option B instead. That keeps Link at checkout and still sends us the card details.

New payments still arrive without card details

Work through these in order:

  1. Another payment configuration still has Link enabled. Repeat Step 1 to list every configuration, including the one your Customer Portal uses.

  2. Your code still passes link in payment_method_types, on the server or in Payment Elements. See Option B.

  3. Your code passes a payment_method_configuration ID that you did not change. The Dashboard change has to be made in that configuration.

If all three check out and new payments still arrive without card details, contact Support.

Renewals still arrive without card details

Those subscriptions are billing against payment methods saved through Link before you made the change, and those do not update on their own. See Existing customers and saved payment methods.

Card details are reaching us but alerts still do not match

Two other causes look the same from your side:

Did this answer your question?