Stripe Link Payments in QuickBooks

Somebody on your team turned on Stripe Link. Possibly nobody did, and Stripe surfaced it because it was eligible. Either way, sales are now arriving through a wallet, and the first time you notice is when a payment in your Stripe data has a card expiry date of 12/2040 and last four digits of 0000.

That record is not corrupt. It is a bank payment that Stripe deliberately dressed as a card, and the fixed values are documented behavior rather than a bug.

Link is worth understanding on the accounting side for a reason that has nothing to do with how it looks to your customer. The same customer, paying the same way, produces two structurally different objects in your Stripe data depending on how your checkout was built. One of those shapes tells you the card brand and the last four digits. The other tells you nothing at all about how the money was funded, and says so on purpose.

Start a free trial and watch how your Stripe sales post before you decide what to do about wallets.

What Link actually is

Stripe describes Link as "Stripe's digital wallet," and the function is the familiar one: it "lets your customers securely save and reuse payment methods for fast checkout."

The authentication flow is the part that makes it a network rather than a feature of your site. Stripe documents three steps. Link "automatically detects if a customer is enrolled by using their email address, phone number, or browser cookie," the customer "receives a one-time passcode to authenticate their session," and after that Link "autofills their card or bank payment details and shipping information."

So a customer who enrolled with Link while buying from somebody else arrives at your checkout already enrolled. You did not save that payment method. Link did, and the customer brought it with them.

What sits behind the wallet is not one thing. Stripe says that "where available, your customers can pay with cards, bank accounts, buy-now-pay-later options, and other methods," and that includes Instant Bank Payments, which Stripe describes as "available exclusively through Link."

That is the whole source of the bookkeeping question. A wallet is a container, and the thing inside it varies.

Link works across most of Stripe's selling surfaces: Checkout, Payment Links, Web and Mobile Elements, and Invoicing. Two availability limits are documented and worth knowing before you plan around it. Link "isn't available in India," and in Brazil and Thailand the Payment Element does not support it.

The two shapes, and why you did not choose between them

Stripe documents two ways to integrate Link, and the choice is made in code by whoever built the checkout. It is not a setting in the Dashboard, and it is not visible from the finance side at all. Both shapes accept the same payment methods. They record them differently.

Link as a payment method. Stripe's recommended integration. In this shape, "all Link transactions have a PaymentMethod object with a type of link." The consequence is stated flatly in Stripe's own documentation: "Because all Link transactions use the link payment method type, the objects associated with them don't expose details about how the customer paid."

Read that twice if you are the person who reconciles. It is not that the details are inconvenient to reach. They are not there. A Link payment funded by a Visa and a Link payment funded by a bank account look identical, because the wallet is what the object records.

Link within a card integration. The alternative, which Stripe says to use "if you only accept card payments, or if you require access to card details such as the brand or last 4 digits." Here "all Link transactions have a PaymentMethod object with a type of card and a wallet type of link," and for card-funded payments "the associated objects include the same card details as for other card payments."

There is a trap in how the two are selected, and Stripe spells it out: "Passing link in the payment_method_types parameter always treats Link as a payment method, even if you also pass card." So an integration that lists both does not get the card shape. It gets the wallet shape, and the card details quietly disappear.

The 12/2040 problem

Now the case that sends people to support, and the reason this post exists.

Take the card integration, where everything arrives as type card. Then let a customer pay through Link with something that is not a card, an Instant Bank Payment or Klarna on Link. Stripe still records it as a card, because that is what the integration asked for. It has no card details to put in the card fields, so it invents them.

Stripe documents the substitutions precisely. Brand is link. Available card networks include only link. Last 4 digits are 0000. Expiration date is 12/2040. Funding is unknown. Display brand is other. All check results are null.

Stripe's own framing is that these are placeholders and should not be shown to anyone: "If your customer interface renders card details, Stripe recommends identifying non-card payments as Link payments instead of rendering the fixed values."

The reason this matters to a bookkeeper rather than a developer is that these values survive. They are on the object. Anything that reads the payment method and writes it somewhere else is reading a card that does not exist, with an expiry sixteen years out and four zeros where the last four digits go. If you ever find yourself investigating a customer whose card apparently expires in 2040, you have found a bank payment, and nothing is wrong.

One more difference between the shapes is worth recording because it changes authorization rates rather than records. Under Link as a payment method, if the customer's Link account holds multiple eligible sources, "Link suggests a backup," and if the customer approves it and the first attempt fails, "Link automatically retries the payment using the backup." Under a card integration, Link "doesn't let customers select a backup payment source during checkout." Fewer declines on one path than the other.

Timing is normalized, and that is the good news

Most payment method questions in accounting are timing questions. A direct bank debit settles on its own schedule, which is why a failed ACH payment can reverse revenue you already recorded, and why bank-funded payments generally need thinking about.

Link does not work that way, and Stripe is unambiguous: "All Link transactions confirm immediately, and successful payments settle to your Stripe balance on the same timeline as card payments, regardless of the payment method that funds the payment."

That is a genuinely useful guarantee. A bank-funded Link payment does not introduce a settlement gap into your books. It reaches your Stripe balance on the card timeline, so it reaches your payout and your clearing account exactly like a card sale.

This is the one place in this post where the answer is "nothing to do." Whatever your close process does with card revenue, it already handles Link revenue correctly.

Fees are not normalized, and that is the other half

Timing is where Link smooths the differences. Pricing is where it does not, and this is a real consequence for anyone on interchange-plus.

Stripe documents a limitation of Link as a payment method: "It doesn't support Interchange+ (IC+) pricing. Stripe bills all such Link transactions at a single blended rate." The same tab lists two further gaps, both relevant only to card-present style flows: no extended authorization, no incremental authorization, and no overcapture.

If your account is on interchange-plus, that is an integration decision changing how a slice of your volume is priced. Your Stripe fee total does not become wrong, but the per-transaction economics of Link sales stop matching the per-transaction economics of everything else, and no report will label the difference for you. The guide to reconciling Stripe fees covers how the fee reaches your books; what this adds is that Link volume under the wallet integration is priced on a different basis from the rest.

Stripe's argument for the trade is real, not marketing: Instant Bank Payments are a lower-cost alternative to cards, so blended pricing on Link can come out ahead even when interchange-plus would have been cheaper on a card. It is worth measuring rather than assuming in either direction.

What reaches QuickBooks

Here the answer is refreshingly short, and the short version is that Link changes nothing about the path.

Acodei's sales sync keys on charge events. A charge.succeeded or charge.captured event becomes an itemized QuickBooks sales receipt deposited into your resolved holding account, with line items resolved through product mapping and unmapped lines falling back to the default product. A Link payment produces an ordinary charge, so it takes the ordinary route. There is no Link support to enable, and nothing about a wallet changes which job runs.

The record type is decided by your account settings. Acodei's documentation is explicit that the routing is made from those settings rather than from the transaction itself, and nothing in it makes the choice depend on how the customer paid. With Sales as Payment enabled, the charge writes a standalone payment against the customer instead, not linked to any invoice. Where the charge belongs to a Stripe invoice that Acodei has already synced, it books a payment receipt applied to that QuickBooks invoice. On a daily summary account there is no per-charge record at all, because charges are aggregated into one receipt per day.

The Stripe fee follows its usual rules too. By default it posts as a negative line on the sales receipt using your mapped fee product, netting the receipt down to what actually entered your balance. Under a fee-as-expense configuration it posts as a separate purchase or expense and the receipt stays gross, which requires a non-Undeposited-Funds payout method.

The one setting where Link is the interesting case

There is a documented path by which a payment method value reaches QuickBooks, and it is the place Link is worth a moment of your attention.

Acodei has an admin toggle, Enable Payment Method on Sales, which adds the payment method to each QuickBooks sales receipt. Its documented purpose is reporting: businesses that need QuickBooks reports broken out by method, with "Stripe" and "Visa" given as the examples. It has one dependency worth knowing, which is that it works only in the sales receipt flow, so with Invoice Sync off. There is a matching Enable Payment Method on Refund for refund receipts, and it has no effect on credit memos.

So if you have that toggle on, something about the payment method is landing on your QuickBooks records, and Link is precisely the case where the underlying value is ambiguous. Under one integration shape the method is a wallet with no funding detail behind it. Under the other it is a card, sometimes a real one and sometimes a synthetic one with a 2040 expiry.

What Acodei's product documentation does not say is which Stripe field supplies that string. It documents that the toggle adds the payment method. It does not document the source field, and it says nothing about wallets, about Link, or about payment method details. So I am not going to tell you what will appear on your receipt, because the honest answer is that the documentation does not settle it and guessing would be worse than useless on a question you can answer definitively in five minutes.

Run one Link sale through your own account, with the toggle in whatever state you actually use, and look at the resulting sales receipt. That single test tells you what your reports will say for every Link sale afterward, which is more than any general answer could. While you are there, check which product the line landed on; if it is not the one you expected, when a Stripe charge maps to the wrong product walks the diagnostic path.

What to actually do about it

Five things, in the order they are worth doing.

Find out which integration shape you have. Look at any recent Link payment and check whether the PaymentMethod type is link or card. That one field tells you which half of this post applies to you, and it is the fact everything else depends on.
Stop treating 0000 and 12/2040 as data. If anything in your process reads card details, those are placeholders for a non-card payment, and Stripe recommends against rendering them at all.
Leave your timing alone. Link settles on the card timeline regardless of funding. No close adjustment, no accrual, nothing.
Check your pricing basis if you are on interchange-plus. Link as a payment method is billed at a single blended rate, and that applies to a slice of volume you may not have separated out.
Test the payment method label rather than predicting it. One real sale, one look at the record.

The general shape of this is familiar if you have read the PaymentMethod entry in our glossary: the type field is the single best predictor of when money lands and what the fee looks like. Link is the case that complicates that rule, because it normalizes one of those two things and not the other. Timing becomes uniform. Pricing does not. And the field you would use to tell them apart is, on the recommended integration, deliberately empty.

Wallets are worth having. Link raises conversion, and the customer experience is genuinely better. It is simply worth knowing that the wallet is a container, that Stripe records the container rather than the contents on its recommended path, and that a bank payment in a card-shaped integration comes with an expiry date nobody should read.

Start a free trial and see how your Stripe sales, wallet payments included, post into QuickBooks.

Frequently asked questions

Does Acodei support Stripe Link payments?

Yes, and there is nothing to switch on. Acodei's sales sync keys on charge events, and a Link payment produces an ordinary Stripe charge. It becomes an itemized sales receipt deposited into your resolved holding account by default, with the record type set by your account settings rather than by how the customer paid.

Why does my Stripe payment show an expiry date of 12/2040?

Because it is not a card. When a non-card payment method such as an Instant Bank Payment is taken through Link inside a card integration, Stripe records it with a type of card and fills the card fields with fixed values: brand link, last 4 digits 0000, expiration 12/2040, funding unknown, display brand other. Stripe recommends identifying these as Link payments rather than rendering the fixed values.

Do Link payments settle more slowly than card payments?

No. Stripe states that all Link transactions confirm immediately and that successful payments "settle to your Stripe balance on the same timeline as card payments, regardless of the payment method that funds the payment." A bank-funded Link payment does not introduce the settlement delay a direct bank debit would.

Can I tell which card a customer used to pay through Link?

It depends on how your checkout was built, and you did not necessarily choose. If Link is integrated as a payment method, the PaymentMethod type is link and Stripe documents that the associated objects "don't expose details about how the customer paid." If Link is integrated within a card integration, the type is card with a wallet type of link, and card-funded payments carry the usual brand and last four digits.

Does Link change what my Stripe fees look like?

It can. Stripe documents that Link as a payment method "doesn't support Interchange+ (IC+) pricing" and that it bills all such Link transactions "at a single blended rate." If your account is on interchange-plus, Link volume on that integration is priced on a different basis from the rest of your card volume.

What payment method will appear on my QuickBooks sales receipt for a Link payment?

Acodei's Enable Payment Method on Sales toggle adds the payment method to each QuickBooks sales receipt, and works only in the sales receipt flow with Invoice Sync off. Acodei's product documentation does not specify which Stripe field supplies that value, and does not cover wallets or Link specifically, so the reliable way to find out is to run one Link sale with your own settings and read the resulting receipt.

Is Klarna through Link the same as Klarna directly?

Not in how it is recorded. Klarna taken as its own payment method behaves like the other buy-now-pay-later methods. Klarna reached through Link inside a card integration arrives with a type of card and Link's fixed placeholder values, because the integration asked for cards. Our guide to Klarna and Afterpay in QuickBooks covers the direct path.