Stripe Payment Links are one of those features that quietly expanded over the last couple of years. What started as a "no-code checkout URL" has turned into a legitimate tool for collecting payments in all kinds of situations, including recovering failed charges. If you've watched a demo and wondered whether you can skip buying a dunning tool and just send Payment Links to customers whose cards failed, this guide is for you.
Short answer: Payment Links solve one specific slice of the failed-payments problem. They don't solve most of it. Here's the honest breakdown.
How Stripe Payment Links work
A Stripe Payment Link is a hosted URL that points to a Stripe-managed checkout page. You create one in the dashboard or via API, tie it to a product or a one-off amount, and share it wherever you want. The customer clicks, enters their card, and pays. Stripe handles the hosted page, the PCI surface, and the receipt.
Key facts:
- You can create a link in about 30 seconds in the dashboard
- Links can be one-time or reusable
- You can collect shipping, tax, and custom fields
- They work with all major payment methods including cards, wallets, and bank debits
- You can pre-fill amounts or let the customer pick
- Each link comes with basic analytics (clicks, conversions)
For one-off recovery, that's enough. If a customer's invoice failed and you want to send them a manual "here's a link to pay" message, a Payment Link does the job.
Where Payment Links genuinely help
Payment Links shine in a few specific failed-payments scenarios:
One-off manual recovery. A customer's card failed, you know them personally, and you want to send a quick "hey, here's a link, can you pay this when you get a chance" email. A Payment Link is faster than walking them through the hosted invoice portal.
High-touch accounts. For enterprise or high-ACV customers where your CS team handles failed payments by hand, Payment Links let the CSM fire a clean payment URL without involving billing engineering.
Invoice-only workflows. If you send invoices (not subscriptions) and occasionally need to collect a one-time payment for a recurring customer, Payment Links work fine.
Ad-hoc collection. Dispute resolution, prorated upgrades, manual adjustments. Payment Links handle these without any extra tooling.
Test and prototype. Before investing in a dunning tool, a founder might manually send Payment Links to the first handful of failed customers to see what the recovery conversation looks like. That's a legitimate use.
Where Payment Links fall short for dunning
Dunning is not "send one link and wait." It's a structured sequence of touches across channels, tied to billing state, with recovery tracking and automation. Payment Links give you the link, nothing else.
No automation
Payment Links don't know when an invoice fails. You're the one who has to notice the failure, create or find a link, and send it manually. At 10 failures a month that's annoying. At 100 failures a month that's a full-time job.
No sequences
Recovery works because of timing and repetition. A good sequence touches the customer on day 0, day 3, day 5, and day 7, often across both email and SMS. Payment Links are a single URL. If you want a sequence, you're building the sequencing layer yourself in a marketing automation tool, then gluing it to Stripe webhooks.
No SMS
Email-only recovery tops out at 50 to 60%. Email plus SMS pushes recovery to 65 to 80%. That's 15 to 20 points of MRR you're leaving on the table if your recovery is email-only, and Payment Links don't have a built-in SMS channel.
No customer context
A dunning tool knows which invoice failed, which customer it belongs to, how many retries have happened, and what sequence step they're on. A Payment Link is context-free. You're passing the customer a generic checkout page that doesn't know anything about their situation.
No recovery tracking
Payment Links give you basic analytics on the link itself: clicks and conversions. They don't tell you "this failed payment was recovered by sequence step 3" because they don't know the payment was ever failed. Your recovery ROI dashboard has to be built somewhere else.
No opt-out handling
If a customer replies "stop emailing me," you need opt-out logic. Payment Links don't handle that. A dunning tool does.
No pre-authentication
Good dunning uses pre-authenticated update links, meaning the customer clicks and they're already logged into their billing state. Payment Links are generic checkout, which means your customer has to re-enter everything. That's friction, and friction kills recovery rates.
Feature comparison: Payment Links vs dedicated dunning
| Capability | Payment Links | Dedicated dunning tool |
|---|---|---|
| Setup time | 1 minute per link | 5 to 30 minutes one-time |
| Automated on failure | No | Yes |
| Email sequences | No | Yes |
| SMS sequences | No | Yes |
| Pre-auth update links | No | Yes |
| Recovery tracking | No | Yes |
| Opt-out handling | No | Yes |
| Multi-step timing | No | Yes |
| Template variables | No | Yes |
| Cost | Free | $29 to $300/mo |
A realistic hybrid approach
If you're bootstrapped and you only see a handful of failed payments a month, you can stitch together a DIY recovery flow with Payment Links plus a small amount of glue:
- Stripe webhook fires on
invoice.payment_failed - Your backend sends a templated email with a Payment Link to the customer
- A Cron job checks three days later, and if the invoice is still unpaid, sends a second email
- At day seven, a final email goes out
This works. It recovers roughly 40 to 50% of failures, which is a lot better than zero. It takes a couple of days of engineering time to set up, and it'll get you through your first $20K of MRR.
Past that, the DIY approach starts to hurt. You're maintaining templates, handling opt-outs, tracking recovery, adding SMS, and debugging webhook retries. At some point the "save $30 a month" calculus flips.
When to graduate to a real dunning tool
Time to stop using Payment Links for dunning when:
- You see more than 20 failed payments a month
- You want SMS in the sequence
- You want recovery ROI tracking built in
- You're spending more than an hour a week on recovery operations
- Your recovery rate is stuck below 50% and you don't know why
- You need to handle multiple Stripe accounts or brands
Where Rekko fits
Rekko is the thing you move to when Payment Links stopped being enough. It connects to Stripe via OAuth, detects failed payments in real time through webhooks, and runs email plus SMS sequences automatically. Pre-authenticated update links come out of the box, setup takes about 5 minutes, and SMS is included at every tier without separate metering.
You keep Stripe as your payment processor. You just stop building the dunning layer by hand.
If you want the even simpler tool, Stripe Billing has basic built-in dunning that works alongside Payment Links. We cover that in our Stripe Billing dunning breakdown. For most SaaS past $10K MRR, a focused tool pays for itself the first week.
Start your 14-day free trial, no credit card required.