How Stripe Payment Links Land in QuickBooks

Stripe Payment Links are the easiest way to take money in Stripe. You make one in the Dashboard, you paste it into an email or a WhatsApp message or a button on your site, and people pay you. No code, no developer, no integration work.

Then you open QuickBooks and want to know what happened to that money.

The short answer is reassuring: a Payment Link sale posts exactly like any other Stripe sale, because by the time it reaches your books it is any other Stripe sale. The longer answer is where the useful part lives. Payment Links arrive through Stripe Checkout, and that changes which field your product mapping reads. Payment Links also let the customer decide what to pay, which quietly breaks one mapping strategy entirely. And a single checkbox on the link can change the QuickBooks record type from a sales receipt to an invoice plus a payment.

This post covers all four. If you sell through Payment Links and your revenue is landing in the wrong QuickBooks account, one of them is almost certainly why.

Start a free trial and see how your Stripe sales post before you commit to a mapping scheme.

A Payment Link is a durable object, not a payment

Stripe describes Payment Links as a way to "accept payments online without writing code," and the object model follows from that. A Payment Link is a thing you create once and keep. It has an id beginning plink_, and a url that Stripe documents as "the public URL that can be shared with customers."

The property that matters for bookkeeping is reuse. In Stripe's own comparison of Invoicing and Payment Links, an invoice goes to "specific individuals or businesses" and cannot be reused, while a Payment Link goes to "anyone with the link" and can be reused "multiple times with multiple customers, or limit the number of purchases."

So one Payment Link can produce a hundred sales. It is a storefront, not a transaction.

What it produces each time someone opens it is a Stripe Checkout Session, and Stripe makes the parentage explicit. The Checkout Session object carries a payment_link field, defined as "the ID of the Payment Link that created this Session." That single field is the whole relationship: the link is the durable template, the session is one person's visit to it.

The link also has an active flag. Stripe's definition is worth knowing if you ever wonder why a link stopped working: "whether the payment link's url is active. If false, customers visiting the URL will be shown a page saying that the link has been deactivated." Deactivating a link does not touch any sale already made through it.

What actually reaches QuickBooks

Nothing about the Payment Link itself reaches your books, and neither does the Checkout Session. What reaches your books is the charge.

Acodei's sales path keys on charge events. A charge.succeeded or charge.captured event is what routes to a sync job and produces a sales record in QuickBooks, and the record type is decided by your account settings rather than by how the payment was collected. On a real-time account the default is an itemized sales receipt, deposited into your resolved holding account.

That is the whole answer to "does Acodei support Payment Links." There is no Payment Link support to switch on, because from the sync's point of view a Payment Link sale is a charge that arrived the same way every other charge arrives.

Two account settings change the record without changing anything about Payment Links:

• With Sales as Payment enabled, the charge writes a standalone payment against the customer rather than a sales receipt, and it is not linked to any invoice.
• On a daily summary account, there is no per-charge record at all. Charges are aggregated into one receipt per day. If you sell through Payment Links on a daily summary account, do not go looking for one QuickBooks row per link click, because that is not how the account is configured to write. Our daily summary versus real-time comparison covers the tradeoff.

The Stripe fee follows the same rules it always does. By default it posts as a negative line on the sales receipt using your mapped Stripe fee product, which nets the receipt down to what actually entered your Stripe balance. Under a fee-as-expense configuration the fee posts as a separate expense instead and the receipt stays gross. The guide to reconciling Stripe fees is the place to sort out which shape you want.

The one genuine difference: description mapping

Here is the part that sends people to support.

Acodei's description-based product mapping does not read one field. It reads a different field depending on how the charge arrived, and the Product Documentation gives three separate lookup orders:

• Charge not linked to a Stripe invoice: charge or payment description first, then the PaymentIntent.
• Charge linked to a Stripe invoice: the invoice line item description.
• Charge linked to a Stripe Checkout session: the product description first, then the Checkout session line item description.

Payment Link sales are in that third bucket. Always, because a Payment Link works by creating a Checkout Session.

So if you wrote description rules against the text you see on your API-created charges, and those rules fire perfectly there and mysteriously never fire on your Payment Link sales, you are not looking at a bug. You are looking at two different fields. The rule is matching against the charge description on one path and against the product description on the other, and those are frequently not the same string.

The fix is boring and effective: set the product description in Stripe to the text your rule expects, or write the rule against the product description in the first place. If a Payment Link sale is landing in the wrong QuickBooks account, when a Stripe charge maps to the wrong product walks the whole diagnostic path.

One more detail on how rules resolve. Acodei evaluates your mapping rules from top to bottom and stops at the first match. A broad rule sitting above a specific one will intercept sales meant for the specific one, and that failure looks identical to "mapping is broken" from the QuickBooks side. Order matters as much as content.

Metadata you put on the link is invisible to mapping

This one is worth stating plainly because the natural instinct is exactly wrong.

The Payment Link object has a metadata map. So does the Checkout Session. If you are organizing your revenue by product line or region or campaign, writing that into the link's metadata feels like the obvious move.

Acodei reads mapping metadata in a fixed order: payment or charge first, then PaymentIntent, then invoice, then subscription.

The Checkout Session is not in that list. Neither is the Payment Link.

So metadata attached to the link or the session is not what metadata mapping matches on. Metadata on the charge or the subscription is. If your no-code setup writes everything useful to the link, metadata mapping has nothing to work with, and you should either move the values onto the objects underneath or map on the Checkout session line item description instead.

There is a related limit worth knowing before you design around metadata at all: Acodei does not currently support multi-key matching, so you cannot write one rule that requires both a region value and a product-type value.

The amount is not yours to predict

This is the difference nobody warns you about, and it is structural rather than a setting.

Acodei offers a transaction value mapping strategy that matches a rule on the gross amount before fees. Set a rule for 9.99 USD and charges at 9.99 USD map to that product. It is simple and it works well for fixed-price products.

Now look at what Stripe documents Payment Links as supporting, in its own feature comparison against Invoicing:

• "Customers can choose what to pay" is supported on Payment Links and not on Invoicing.
• "Customers can edit quantities" is supported on Payment Links and not on Invoicing.
• Promotion codes and discounts are supported.
• Optional items and upsells are supported.

Every one of those makes the final charge amount something the customer decided, not something you set. Acodei's own documentation flags the mechanism directly: promotional discounts can cause the final charge amount to differ from the base product amount, which breaks the match unless you configure a separate rule for the discounted price.

With a Payment Link that has promo codes on and quantity editing on, there is no finite set of prices to write rules for. Two units with a 20 percent code off is a number you never anticipated.

So the practical guidance is a recommendation rather than a rule from the docs: on Payment Links carrying promotion codes, optional items, or customer-chosen amounts, map on the Stripe product rather than the amount. Product mapping uses the product and price ids, which do not move when the customer changes the quantity or applies a code. Amount matching is the one strategy whose input the customer controls.

If you do use amount rules elsewhere, note that the currency has to match too. A rule set in USD does not match the same numeric amount in CAD, which becomes live the moment Stripe's Adaptive Pricing shows a customer their local currency.

Turning on invoice creation changes the record type

Payment Links have an invoice_creation setting, which Stripe describes as "configuration for creating invoice for payment mode payment links." Switch it on and each sale through the link also produces a Stripe invoice. The Checkout Session then carries an invoice field holding "the ID of the invoice created by the Checkout Session, if it exists."

For your books this is not a cosmetic change. It can change what QuickBooks records you get.

The condition is whether Invoice Sync is enabled on your Acodei account. It is available on paid plans, it has to be switched on deliberately under Account Mapping in the Premium Features block, and it is toggled per company.

With Invoice Sync off, the Stripe invoice is not synced. The charge is not linked to anything Acodei has written, so it takes the ordinary sales path and you get one sales receipt. Same as any other Payment Link sale.

With Invoice Sync on, Acodei creates a QuickBooks invoice when the Stripe invoice is finalized. The charge then belongs to an invoice that Acodei has already synced, and that routes it differently: instead of a sales receipt, it books a payment receipt applied to that QuickBooks invoice.

So the same Payment Link, with the same customer paying the same amount, produces one sales receipt in one configuration and an invoice plus an applied payment receipt in the other. If you have accounts receivable reporting that depends on invoices existing, that difference is the entire point. If you do not, it is two records where you expected one.

The fee treatment moves with it. On the invoice path the Stripe fee posts as a separate expense, because Acodei never adds Stripe fees to an invoice. Adding them would make the QuickBooks invoice total disagree with the Stripe invoice total, and the customer never owed the processing fee in the first place.

Synced invoices also pick up the invoice number suffix, which appends -AC1, -AC2 and so on by default so that synced invoices cannot collide with numbers you assign by hand in QuickBooks. If you need the full picture of how invoices rebuild, what a Stripe invoice resync does covers the numbering behavior and its documented gap.

A short checklist before you scale up Payment Links

If you are about to send a Payment Link to a real list, five minutes here saves a month-end.

1. Decide the mapping strategy first. Product mapping if the link has promo codes, optional items, quantity editing, or customer-chosen amounts. That is most Payment Links.
2. Check where your description rules point. Payment Link sales read the product description, then the Checkout session line item description. Not the charge description.
3. Put mapping metadata on the charge or the subscription, not on the link or the session, or skip metadata mapping for this path.
4. Decide about invoice creation deliberately. On plus Invoice Sync means invoices and applied payments in QuickBooks. Off means sales receipts. Neither is wrong, but pick one on purpose.
5. Run one real sale through the link and look at the QuickBooks record before you send the link to anyone else. One test transaction tells you more than any amount of configuration review.

The reason Payment Links deserve this attention is not that they are complicated. They are the simplest thing Stripe sells. It is that they are usually set up by whoever needed to get paid this week, and mapping is usually set up by whoever closes the books, and those are frequently not the same person and frequently not the same month.

Start a free trial and watch a Payment Link sale post into QuickBooks with the mapping you chose.

Frequently asked questions

Does Acodei support Stripe Payment Links?

Yes, and there is nothing to enable. Acodei's sales path keys on charge events, and a Payment Link sale produces an ordinary charge. It posts as a sales receipt by default on a real-time account, with the record type set by your account settings rather than by how the payment was collected.

Why does my Payment Link sale map to the wrong QuickBooks product?

Most often because description mapping reads a different field on this path. A charge linked to a Stripe Checkout session resolves its description from the product description first and the Checkout session line item description second, rather than from the charge description used on non-invoice charges. A rule written against the charge description will not match. Rule order matters too, since Acodei evaluates rules top to bottom and stops at the first match.

Can I map on metadata I set on the Payment Link?

No. Acodei reads mapping metadata from the payment or charge, then the PaymentIntent, then the invoice, then the subscription. Neither the Payment Link nor the Checkout Session is in that order. Move the values onto the charge or the subscription, or map on the Checkout session line item description instead.

Do Payment Link sales create invoices in QuickBooks?

Only if you turn on invoice creation for the link and have Invoice Sync enabled in Acodei. With both on, the Stripe invoice syncs to a QuickBooks invoice and the charge books as a payment receipt applied to it. With either off, the sale takes the ordinary path and posts as a sales receipt.

Why do amount-based mapping rules keep missing on Payment Links?

Because Payment Links let customers change the amount. Stripe supports customer-chosen amounts, editable quantities, promotion codes, and optional items on Payment Links, and Acodei's transaction value matching compares the gross amount against a fixed number you configured. A discounted or multi-unit purchase produces an amount no rule anticipated. Map on the Stripe product instead.

Does an abandoned Payment Link visit show up in QuickBooks?

No. Opening a Payment Link creates a Checkout Session, and a session that never produces a charge produces no QuickBooks record. The count of sessions in Stripe will always exceed the count of sales in your books, and that is the correct outcome rather than missing data.

How do Stripe fees on Payment Link sales post to QuickBooks?

The same way they do for any other charge. By default the fee is a negative line on the sales receipt using your mapped Stripe fee product, which nets the receipt to what entered your Stripe balance. Under a fee-as-expense configuration it posts as a separate expense and the receipt stays gross. On the invoice path the fee always posts as a separate expense, because Acodei never adds fees to a synced invoice.