AddPaymentInfo is missing from your Shopify Meta events because nothing is sending it. Meta doesn’t watch your checkout; it only counts events that arrive. If InitiateCheckout and Purchase show up but AddPaymentInfo never does, whatever sends your Meta events is listening for the start and the end of checkout, and not for the payment step in between.
On Shopify that gap is common, and it has a specific shape. The payment step sits inside Shopify’s checkout, where your theme’s code doesn’t run. Only a sender that subscribes to Shopify’s own checkout payment event can report it.
This is fixable. The work is finding which sender is supposed to own AddPaymentInfo, making it listen to the right event, and testing all the way through a paid order.
What does AddPaymentInfo do in Meta, and does it matter?
AddPaymentInfo is a standard Meta event for the moment a shopper enters payment details during checkout. It sits between InitiateCheckout and Purchase. Meta uses it for audiences and reporting on the late checkout stage. It matters less than AddToCart or Purchase, but a missing step hides exactly where checkouts stall.
Be honest with yourself about the stakes. Your purchases are still counted without it, and your campaigns can still optimise for Purchase.
What you lose:
- The payment-stage drop-off. You can’t separate “left at shipping” from “left at payment” in your funnel.
- A late-funnel audience. A retargeting audience built on “entered payment info but didn’t buy” has nobody in it.
- A signal for thin accounts. A store with few purchases a week gives Meta fewer events to learn from. Every real funnel step it can see helps a little.
If a missing AddToCart is the bigger hole in your setup, fix that first. Why Meta says your Shopify store sent no AddToCart events covers that gap.
Why do InitiateCheckout and Purchase fire but AddPaymentInfo doesn’t?
Because the sender you rely on subscribes to checkout started and checkout completed, and not to the payment step. On Shopify’s current checkout, custom code can’t be pasted into checkout pages; tracking code runs as a pixel that subscribes to named checkout events. A pixel only reports the events it subscribes to, and the payment step is the one most setups leave out.
Work through the usual causes in this order.
The pixel never subscribes to the payment event. Shopify’s Customer Events publish a payment_info_submitted event for the checkout payment step. Many copy-pasted custom pixels subscribe to checkout_started and checkout_completed and stop there. InitiateCheckout and Purchase flow; AddPaymentInfo never does. Open each custom pixel under Customer Events and search its code for payment_info_submitted. If it isn’t there, you have found the gap.
Your old checkout code stopped running. Stores that once pasted Meta pixel code into checkout scripts or the old checkout template lost it when Shopify moved checkout to its newer, locked-down version. Code there that fired AddPaymentInfo on a payment-page load or a button click no longer runs. Shopify’s thank-you and order-status page upgrade did the same thing to purchase tracking, as covered in why ad conversions dropped to zero after Shopify’s thank-you page upgrade.
Your Meta app doesn’t send it for your checkout. If you rely on a sales channel app or a third-party pixel app, check which events it actually delivers. Events Manager lists each event by the integration that sent it. If AddPaymentInfo isn’t listed under your app’s connection, that app is not sending it for your store, whatever its settings page suggests.
Express wallets skip the payment step. Buyers who pay with Shop Pay, Apple Pay, Google Pay or PayPal from an express button may never fill in Shopify’s payment form, because the wallet holds their card. Depending on the path, there may be no separate payment step to report. That explains a low AddPaymentInfo count against orders. It rarely explains zero, because card buyers still walk through the form.
Code that depends on an earlier event. If your pixel stores something at checkout_started and reads it again at the payment step, a shopper who entered checkout by a shorter route can make that handler fail silently. Why a Shopify custom pixel doesn’t fire on Shop Pay orders walks through that bug in detail.
AddPaymentInfo goes to another dataset. Two installs, two pixel ids. One sends the payment step to a dataset nobody looks at.
How do you test whether AddPaymentInfo is being sent?
Walk a real checkout past the payment step while watching Events Manager’s Test Events tab. Stopping at the shipping page proves nothing, because the payment event only exists once payment details are submitted. Use a test payment method or a small real order you refund, and check which events arrive, from which connection, for which dataset.
- Confirm the dataset. Note the pixel or dataset id your ads optimise on, and check every app and custom pixel points at it.
- Test with a card, not an express button. Go product page, cart, checkout, and fill in the payment form yourself. This is the path most likely to produce a payment event.
- Watch for AddPaymentInfo before Purchase. It should arrive once per checkout, ahead of the order.
- Repeat with an express wallet. If the card path works and the wallet path shows nothing, your gap is wallet skip, not broken code.
- Read your custom pixels’ subscriptions. List what each one subscribes to and look for
payment_info_submitted.
Send your test events with a test event code so they stay out of your live data. Testing Meta CAPI without polluting live data covers the setup.
How do you fix missing AddPaymentInfo on Shopify yourself?
Give AddPaymentInfo one owner and have that owner subscribe to Shopify’s payment_info_submitted event. That is the only supported place to hear the payment step on the current checkout. Map it to Meta’s AddPaymentInfo with the value, currency and product ids from the checkout, and remove any older sender.
Subscribe to the event. In your custom pixel, add a subscription to payment_info_submitted and send Meta an AddPaymentInfo from it. Pull the checkout total, currency and line items from the event data rather than from something you stored earlier.
Use the same content ids as your other events. If AddToCart and InitiateCheckout send variant ids, send variant ids here too, so Meta can connect the steps to the same catalog items.
Pick one source per event. If a Meta app already sends AddPaymentInfo and you add a custom pixel that sends it too, switch one off. Two tools with their own event ids produce two events per checkout.
Add a server copy. Browser events are lost to ad blockers and to shoppers who close the tab mid-checkout. Sending AddPaymentInfo through the Conversions API keeps it arriving when the browser doesn’t cooperate. If you send both a browser and a server copy, they need the same event name and event id so Meta counts one.
Keep the Meta base pixel on the storefront throughout. It sets the _fbp cookie that server events use for matching.
How does PartialLeads send AddPaymentInfo from Shopify to Meta?
The PartialLeads Customer Events pixel captures the checkout payment step, Shopify’s payment_info_submitted event, and PartialLeads sends it to Meta server-side as AddPaymentInfo. Because it listens to Shopify’s own checkout event rather than a page or button, the checkout upgrade that broke pasted scripts doesn’t break it.
The whole funnel, from one install. On the Shopify pixel path, PartialLeads sends ViewContent, AddToCart, Search, InitiateCheckout and AddPaymentInfo server-side. Purchase comes separately from Shopify’s order webhooks, once the order is paid. Meta gets each step between the product view and the sale.
Variant ids on every ecommerce event. Ecommerce events send the variant id as content_ids, falling back to the product id, so AddPaymentInfo lines up with AddToCart and InitiateCheckout.
Sent once, retried safely. Each event carries a deterministic event_id built from the pixel id, event name and record id, so a retry can’t create a second copy. Auth failures flag the connection for reconnecting; transient failures retry on the next cycle.
Identifiers handled. Customer data is normalised and SHA-256 hashed before sending. When fbclid is on the landing URL but the _fbc cookie is missing, PartialLeads rebuilds _fbc from it. It does not create _fbp; that still needs Meta’s base pixel.
Where you see it working. The Meta CAPI page shows AddPaymentInfo counts beside InitiateCheckout and Purchase, with each delivery in the activity log. For a single shopper, the Journey timeline shows the payment step between their checkout start and their order.
The honest constraints. PartialLeads hears the same Shopify event your own custom pixel would. If an express wallet path never publishes a payment step, there is nothing to send, so expect fewer AddPaymentInfo events than orders. Its event ids are its own: it never sends twice, but it does not deduplicate against a Meta app or another pixel sending AddPaymentInfo, so switch the other sender off. And delivery is the half it controls. Whether Meta ties each event to a person depends on the identifiers captured and Meta’s own matching. For the wider Shopify setup, see how to fix Meta CAPI tracking on Shopify.
| What breaks | The mechanism | Where you see it in the dashboard |
|---|---|---|
| Custom pixel skips the payment step | Customer Events pixel captures payment_info_submitted |
Meta CAPI page, AddPaymentInfo per day |
| Old checkout scripts stopped running | Listens to Shopify’s checkout event, not a page or button | Meta CAPI activity log |
| Browser event lost to blockers or closed tabs | AddPaymentInfo sent server-side to Meta | Activity log, delivery status |
| Steps don’t line up on the same products | Variant id as content_ids on every ecommerce event |
CAPI payload per event |
| Two senders for one payment step | Not deduplicated against other apps — keep one source | Events Manager senders vs the Meta CAPI page |
Tell us what's broken. We'll fix your tracking — free.
Describe the tracking/attribution problem you're stuck on and we'll map it to a fix: server-side conversions to Meta, Google, TikTok and Pinterest, plus first-party tracking that survives Safari. No code required.
Sources
- https://developers.facebook.com/docs/meta-pixel/reference
- https://developers.facebook.com/docs/marketing-api/conversions-api
- https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/server-event
- https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/custom-data
- https://developers.facebook.com/docs/marketing-api/conversions-api/deduplicate-pixel-and-server-events
- https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/fbp-and-fbc