Why Shopify App Attribution Breaks on Razorpay Magic Checkout & GoKwik

In short

If your store runs a third-party checkout overlay like Razorpay Magic Checkout, a large share of your orders never carry the Shopify cart and checkout tokens that on-site recommendation and personalization apps use to attribute revenue. Those orders are invisible to the token join, permanently, from the order webhook. So the "attributed revenue" you read from any such app is a number computed over a partial slice of your orders, not all of them. On one store we work with, roughly 35% of orders arrived through Razorpay Magic Checkout and were token-invisible. The direction of the resulting error is not obvious: you get under-reporting from missed joins, and you can get over-crediting from apps that fall back to weaker signals. This post explains the mechanism and gives you a checklist to test it on your own store.

This is the third post in our attribution thread. The first, why fashion recommendation apps rarely build real outfits, is the keystone. The second, how to read a Shopify app's attributed revenue, covered view-based credit, cross-app double-counting, and the gap between attribution and incrementality. This one is about the checkout layer, which sits underneath all of that.

How on-site apps attribute revenue in the first place

A recommendation or personalization app watches a shopper click something, then needs to know if that shopper bought. The app never sees your payment processor. It sees Shopify's orders/create webhook after the fact. To connect "this person clicked" with "this order happened," the app needs a shared key on both sides.

The historical key is the cart token. Shopify defines cart_token as a unique value referencing the cart associated with the order, and checkout_token as the value referencing the checkout. When a shopper builds a cart on your storefront and moves through Shopify's native checkout, both tokens flow into the order payload, and the app can join its click log to the order. Shopify's own documentation notes that cart_token is null for orders made through POS or the admin control panel, because those orders never originated from a storefront cart. That exception is the whole story here, because a checkout overlay reproduces exactly that condition.

What a checkout overlay actually does

Razorpay Magic Checkout replaces Shopify's native checkout with its own overlay. The shopper taps checkout, Razorpay's modal takes over address, coupon, COD, and payment, and then Razorpay places the order into Shopify programmatically. Razorpay's own web integration doc describes the fallback path plainly: if no confirmation call arrives within a set window, "our background job will assume there is a network drop off and will proceed to place the order on Shopify automatically." The order is created by Razorpay's backend through the API, not by a shopper walking through Shopify's cart-to-checkout flow.

That is the crux. An order created through the API, rather than through the native storefront cart and checkout, sits in the same bucket as a POS or admin order for token purposes. The cart token and checkout token are null or absent, because there was no Shopify-side cart and checkout session to reference. Shopify developers report exactly this: on sessions that complete through an external payment gateway, the orders/create and orders/paid webhooks arrive without a cart token. The same behavior is documented for other overlay-style integrations. One developer found that orders processed through ReCharge "are stripped of their cart_token and checkout_token fields," verified across the orders/create, checkout/create, and checkout/update payloads.

There is a second, quieter tell. Razorpay documents that after integration, "updates regarding conversions will only be visible in the Order Analytics tab on the Razorpay Dashboard and not in Shopify Analytics." When the checkout layer keeps its own conversion ledger and does not feed Shopify's, that is the same fragmentation showing up in your own analytics, not only in a third-party app's.

Why the error is not simply "under-counting"

The intuitive read is that missed joins mean the app under-reports, so the true number is higher. That is half right. Two things complicate it.

First, apps do not all fail the same way. An app that relies purely on the cart-token join goes silent on overlay orders and under-reports. An app that falls back to a looser signal, such as matching on email plus a time window, or crediting any purchase within a click window regardless of whether the clicked product is in the order, can credit itself for overlay orders it had nothing to do with. That is over-crediting on the same population where the strict app under-reports.

Second, the invisible orders are not a random sample. In India they skew toward COD, toward first-time and price-sensitive buyers, and toward the exact shopper segments an overlay is installed to convert. So the orders you are missing may behave differently from the orders you can see. Attributing over the visible slice and projecting to the whole store assumes the two slices are alike, and there is no reason to assume that.

This is an order-population problem before it is an attribution-model problem. Any rate you compute (attributed revenue share, conversion lift, revenue per session) is computed over the population your key can see. If that population is 65% of orders on a store with Magic Checkout at 35%, the denominator is quietly wrong and every rate built on it inherits the error.

Which layers keep the token, and which drop it

The table below is a starting map. Treat the overlay rows as "verify on your own store," because behavior changes with integration mode and version. GoKwik in particular ships more than one integration style, and at least one integration guide describes a newer mode that adds blocks into Shopify's own checkout rather than redirecting to a separate modal. When it uses native checkout, tokens survive. When it uses the off-site modal, they do not.

Checkout layer	Does the Shopify cart/checkout token survive to the order?	What a merchant should check
Native Shopify checkout (including Shop Pay, Apple Pay, Google Pay accelerated buttons)	Yes in the standard cart flow. Accelerated buttons that skip the cart can break token continuity, so confirm per path	Pull recent web orders and confirm `cart_token` is populated
Razorpay Magic Checkout	No. Order is placed via Razorpay's background job/API, so cart and checkout tokens are null or absent	Check `cart_token` on Magic Checkout orders; look for a token stuffed into `note_attributes` instead
GoKwik Kwik Checkout	Depends on integration mode. Off-site modal drops tokens; native-checkout mode preserves them	Confirm which mode you run; a Shopify forum reply notes GoKwik "seems to skip shopify's checkout process altogether" and "breaks attribution for other apps"
Shiprocket Checkout (Fastrr)	Likely dropped in the redirect flow, not independently confirmed for every mode	Verify on your store; third-party tracking guides group it with GoKwik as an off-domain checkout that breaks purchase tracking
Simpl 1-Click Checkout	Not verified. Overlay-style one-click flow, treat as at risk	Place a test order and inspect the order payload
Snapmint / BNPL layers	Not verified	Place a test order and inspect the order payload

How to check this on your own store

You do not need engineering help for the first pass.

Segment your orders by source. In Shopify admin, look at where orders come from, and separately open your overlay vendor's own dashboard (for Magic Checkout, the Razorpay Order Analytics tab). If the two order counts diverge, you already have your fragmentation estimate.
Pull a sample of recent orders through the admin API and read cart_token and checkout_token. If a chunk of orders show null tokens, note their source and payment gateway. Overlay orders are the usual cause.
Check note_attributes on those same null-token orders. Overlays and apps often stuff a substitute token there precisely because the native field is null. If you see one, an app could in principle join on it, but only if it was built to.
Compare the order count your recommendation app reports as "eligible" against your true total order count for the same period. The gap is the slice the app cannot see.

What to ask your app vendor

Send these five questions to any recommendation, personalization, upsell, or search app you pay for. Vague answers are the finding.

What key do you join clicks to orders on: cart token, checkout token, line item properties, email plus time window, or something else?
On orders that arrive with a null cart token, what does your attribution do? Does it drop them, or does it fall back to a looser match?
Do you explicitly handle stores running Razorpay Magic Checkout, GoKwik, Shiprocket Checkout, or similar overlays?
Is your reported "attributed revenue share" computed over all store orders, or only over orders you can join?
What is your attribution window, and is it click-based or view-based?

On that last question, here is where the main apps stand as of July 2026, from their own public documentation. Rebuy opens attribution with a 24-hour window: per its help center, "Clicking on the product in the widget redirects the customer to the product detail page and starts a 24-hour attribution window, during which Rebuy sets a cookie." It then writes hidden line item properties that its developer docs confirm "are all prefixed with an underscore '_' because Shopify hides properties prefixed with an underscore by default," so the durable join is the line item property rather than the cookie. Nosto uses same-session Click & Buy for onsite recommendations, with a 30-minute session, extended to the same session plus 24 hours for email widgets. LimeSpot documents a 7-day click-based window as its default, which it describes as the shortest of the industry-standard windows (90, 45, 30, 14, or 7 days). Wiser and Glood publicly market analytics dashboards that track widget-driven sales but do not, as far as we can find, publish a specific attribution window. Stylitics describes a "Direct Click Attribution" model in its case studies but does not publish a standard window either. Crucially, none of these vendors document what their attribution does on a store running a third-party checkout overlay. That silence is the point of this post.

The line-item-property alternative, and its limits

There is a more robust join than the cart token, and Rebuy is the clearest public example of it. Instead of relying on a token that lives on the checkout session, the app writes attribution data as hidden line item properties onto the cart line itself: keys like _source, _attribution, and _widget_id. Because those properties ride on the line item, they can survive into the order even when the checkout session token does not, as long as the overlay reads and preserves the Shopify cart line items when it creates the order.

That "as long as" carries real weight. Line item properties can be stripped or not rendered depending on the theme and packing-slip setup, they can be disabled in the app's own settings, and they can be disturbed when another app also writes to the cart line or when the overlay rebuilds the cart on its side rather than passing it through. Shopify has also added a cartToken field to the GraphQL Admin API Order object in the 2026-07 version, and has flagged the older cart_token and checkout_token order fields for deprecation, so the plumbing here is actively shifting. The practical takeaway is that a line-item-property architecture degrades more gracefully on overlay stores than a pure token join, but it is not immune, and no app should be assumed to use it unless it says so.

Why this matters more in India

The overlay layer is not a niche. Razorpay holds roughly 55% of India's online payment gateway market, and Magic Checkout is a headline product built to attack the last-step drop-off. Razorpay's own material puts cart abandonment at around 70%, and Magic Checkout claims a 22% reduction against it. Checkout overlays cluster on exactly the merchants who lean on COD, which per Emerge Digital's State of Shopify in India 2026 "accounts for 42% of India D2C orders" while carrying "a 24-38% return-to-origin (RTO) rate, quietly destroying margins on the back end." For fashion specifically, COD share and RTO both run higher. So the Indian fashion D2C store is the most likely to run an overlay, the most likely to have a large token-invisible order slice, and the most likely to have that slice behave differently from its prepaid orders. If you are reasoning about average order value on these stores, our India AOV playbook assumes you can measure it cleanly, and this is the measurement problem sitting underneath that.

FAQ

Does Razorpay Magic Checkout really make orders invisible to my apps?

It makes them invisible to any app that joins clicks to orders using the Shopify cart or checkout token. Magic Checkout places the order through Razorpay's backend rather than Shopify's native checkout, so those tokens are null or absent on the order. Apps that use a different join, such as line item properties, may still see the order.

Is the missing revenue being under-counted or over-counted?

Both can happen. An app that only uses the token join under-counts, because it drops the overlay orders. An app that falls back to a looser match, like email plus a time window, can over-count by crediting overlay orders it did not influence. You cannot know the direction without checking how your specific app behaves on null-token orders.

How do I know how many of my orders are affected?

Compare the order count in your overlay vendor's dashboard against your Shopify order count, or pull recent orders via the admin API and count how many have a null cart_token. The share of null-token orders from your overlay is your affected slice.

Does this apply to GoKwik and Shiprocket too?

It applies to any layer that creates the order off the native checkout flow. GoKwik ships more than one integration mode, and only the off-site modal mode drops the tokens, so confirm which mode you run. Shiprocket Checkout is grouped by third-party tracking guides with the same off-domain pattern, but verify on your own store rather than assuming.

Will Shopify's checkout changes fix this?

Not directly. The checkout.liquid sunset and the move to checkout extensibility change how the checkout is customized, not how a third-party overlay creates orders. Shopify has added a cartToken field to the GraphQL Admin API Order object in 2026-07, but a token can only be populated if a native cart existed, so overlay orders remain the gap.

What is Angadi's own attribution window?

Angadi uses a deliberately conservative 24-hour click-based window. We would rather under-claim than credit ourselves for purchases we did not influence, which is also why we think every merchant should ask the population question before trusting any attributed-revenue number, including ours.

Disclosure

Full disclosure: Angadi is our product.