Repository navigation
docs: payments are trackEvent with payment fields in eventData, capturePayment deprecated - #265
Open
ChetanBhosale wants to merge 16 commits into
Open
ChetanBhosale wants to merge 16 commits into
ChetanBhosale wants to merge 16 commits into
Conversation
…ePayment The SDK guides, API reference, SDK-less guides, feature pages and testing guide now send payments through trackEvent / capture-event with amount, payment_id and currency. The event name becomes the payment type. removePayment and remove-captured-payment are no longer documented, and there is no replacement. The Appbrew page is unchanged because its tracker still calls capturePayment and removePayment. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
New page sdk/migrate-to-track-event covers the deprecation, the event naming rule (old payment types keep their mappings, new names need one), before/after code per platform, field mapping and the server API. SDK guides and the API reference link to it and state the naming rule. The revenue sharing sections now send revenue as the payment amount instead of an amount inside eventData. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Each SDK guide now leads Tracking Payments with trackPayment (type renamed to eventName, currency required, userId still required, status defaults to PAYMENT_COMPLETED), with trackEvent plus a payment as a short alternative. Every payment example carries userId. The migration guide maps capturePayment to trackPayment field by field. The Unity bridges pass userId to the 5.0.0 EventPayment and the wrapper gains TrackPayment. API pages explain that user_id links a payment to your user. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Add sdk/track-payments with how a payment flows from trackPayment to reports, ad networks and analytics, a fields table with why each field is required, a payment status section with a lifecycle walk-through, and examples for every SDK (one-step purchase with products, status lifecycle, subscription renewal with an old type name) plus how each SDK reports an invalid payment, ad network revenue rules, deduplication, verification steps and an FAQ. Migrate page: inline field comments, eventData product details and a with-status example in every platform tab, PaymentStatus constants for JS SDKs, and payment rules that say why each field is required. Link the guide from each SDK's Tracking Payments section, the revenue tracking API page and the events and payments testing page. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…ch SDK guide The Tracking Payments example in each SDK guide now sets every parameter the SDK accepts, with a one-line comment for each: whether it is required, what it is for, and its default. eventId appears only where trackPayment takes it (Android Kotlin, iOS, Capacitor). Each guide also gets a PaymentStatus subsection that shows the enum as that SDK defines it, plus a table of when to use each status and what it does. The parameter table now has a Default column. Expo gets a compact full example that uses the rn-linkrunner API. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This was referenced Oct 24, 2026
Open
Open
feat: payments through trackEvent, capturePayment removed (4.0.0)
linkrunner-labs/expo-linkrunner#22
Open
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Payments are now documented as in-app events sent with
trackEvent: putamount,paymentIdandcurrency(plususerIdand optionalstatus) ineventData.trackPaymentand the payment object are gone from every example;capturePaymentandremovePaymentare marked deprecated for the old SDK versions.Pages
sdk/migrate-to-track-event(rewritten, "Migrate payments to in-app events"): before/after per SDK at the top with product details, the same-spelling warning (FIRST_PAYMENTmust stay uppercase or Meta/Google mappings won't match), 3-step migration, field table, old types list, versions, refunds viaPAYMENT_CANCELLED, new names need a mapping, server API.sdk/track-payments("Track payments with trackEvent"): every tab converted, payment keys table, statuses, per-platform behaviour on an invalid payment (Android rejects/throws, iOS drops and logs).api-reference/event-capture,api-reference/revenue-tracking(website payments stay on/capture-paymentwithsource: web), testing, events tab, Google commerce manager, SDK-less minimal guides.SUBSCRIPTION_RENEWED,WALLET_TOPUP).Checks
npm run check:agentsandnpm run check:routes -- origin/mainpass (135 pages, no unredirected removals).trackEvent(eventName, eventData, eventId), FlutterPlatformException(TRACK_EVENT_FAILED)on Android.SDK PRs: linkrunner-labs/linkrunner-android#41, linkrunner-labs/linkrunner-ios#33, RathodDarshil/linkrunner#45, RathodDarshil/rn-linkrunner#47, linkrunner-labs/expo-linkrunner#22, linkrunner-labs/capacitor-linkrunner#13, linkrunner-labs/cordova-linkrunner-sdk#8, linkrunner-labs/linkrunner-unity-sdk#4. Backend: linkrunner-labs/hazelnut#884.
Linear: https://linear.app/linkrunner/issue/LIN-3231/in-app-events-trackevent-with-amount-becomes-the-payment-api
🤖 Generated with Claude Code