External Payment Links Turn Scattered Purchase Records into an Evidence Ledger

External payment links are opening up a service opportunity: turning scattered purchase records from app operations into a ledger that can support reporting and review.

The link opened, but ledger obligations followed

Google Play now permits links that let users in the United States and US territories buy digital goods on a web page outside the app or download an external app. Participation is optional, but operators using external links must register their Play app. If they provide a link to download an external app, they must also register and obtain approval for that external app, then record transactions and installations in the required format.

According to Google’s schedule guidance, transaction-reporting and related fee obligations are expected to begin on October 1, 2026. The deadline for reporting successful external-app downloads and paying related fees has been extended to December 1, 2026, so these should not be treated as the same deadline.

Whether a fee applies depends on whether a user completes a transaction or installs an external app within 24 hours of clicking the link. Records must cover not only paid purchases, but also zero-value transactions created by free trials, subscription renewals, top-ups, product changes, and refunds.

The external-app installation fee is US$2.85 per successful installation for a standard app and US$3.65 for a game. The guidance converts these to roughly KRW 3,900 and KRW 5,000. At 10,000 successful installations, that is roughly KRW 39 million and KRW 50 million respectively, making this difficult to treat as a minor incidental cost.

Report records include a value that identifies the app name, an internal transaction number, pre-tax amount, tax, transaction time, status, and post-refund amount. Operators must link the external transaction token and their internal transaction ID in the payment record before reporting it. Building the link button is therefore only the start; maintaining the ledger remains the longer task.

How a day changes at a 12-person app company

Consider a Seoul-based habit-tracking subscription app with 12 employees and paying users in the United States. Each day, its operations lead downloads separate files for app link clicks, transactions from the web payment provider, and records from the subscription-management screen.

They match external transaction tokens to payment numbers, exclude transactions completed after 24 hours, and separate free trials from paid conversions. When there is a refund, they find the original purchase row again and update its amount and status. For unmatched records, they message a developer.

At month-end, they copy the same numbers again into a ledger for the finance team and a record for Google reporting. The payment provider shows authorization time, the app shows link-click time, and the subscription system shows renewal time, so explaining which record is the reference takes time.

A record-ledger service could store external transaction tokens and internal transaction IDs, then automatically collect payment, renewal, and refund records. It could group the same transaction into one row, indicate whether it is reportable and which deadline applies, and produce submission records in the required format.

The operations lead’s first task would change too. Instead of combining three files, they would check only previous-day US transactions that remain unmatched, reports that are late, and expected fees that have risen suddenly.

Some work would still require human judgment. Staff must assess ambiguous cases about whether a user is in the United States, wrongly classified apps, partial refunds, and customer disputes. Final submission and payment remain the app operator’s responsibility.

Other companies can build similar screens and calculations. What is harder to copy is data accumulated from payment-provider-specific errors and refund cases, the ability to show how a particular number was produced, and distribution through accountants, payment providers, and app makers. If a service also builds experience explaining historical records under new rules whenever those rules change, trust in the ledger can outlast the technology.

Patterns from places already operating this model

Google Play’s external payment programme in Japan

In Japan, a programme is operating that lets apps and games send users to an external website or an installed payment app. The fee for automatically renewing subscriptions is 10%, while other digital goods generally carry a 20% fee. Transactions completed within 24 hours of opening the link are the basis for this treatment.

Zero-value transactions created by free trials must also be reported, and Google Play billing must still be offered alongside the external option. No results from individual participating companies have been published. But the fact that games can participate and that the number of links is not limited shows that a system combining permitted links with transaction ledgers is already in operation.

Spotify’s User Choice Billing

Spotify announced that it was the first partner to adopt Google’s User Choice Billing in November 2022. It began by giving Android subscribers in selected markets a screen to choose between Google Play billing and Spotify billing.

Country-level usage shares and individual fee terms were not disclosed. Still, this is a real example of a large subscription app adding a payment choice.

Jio Payments Bank’s transaction matching in India

Jio Payments Bank in India used FSS Smart Recon to match transaction records across multiple payment networks and e-wallets. The approach detects differences between payment and settlement records arriving from different sources and supports dispute and settlement management.

FSS said it processed more than 1 million transactions per day and matched records ten times daily for real-time payments. These are figures from the supplier’s own case study and need separate verification. But they make one point clear: as record volumes rise, services that surface only mismatched transactions become more useful than having people review every transaction.

Four ways to start small

1. A US external-payment record ledger

• What: A service that connects an external transaction token and an internal transaction ID with purchases, renewals, and refunds in one row, then creates records for Google reporting.
• Who: A Korean subscription-app company with paying US members and only one or two operations staff.
• Why now: Transaction-reporting and fee obligations are expected to begin on October 1, 2026, so operators need to build test records in advance.
• First screen: Yesterday’s US link clicks, matched purchases, failed matches, and the next reporting deadline.

2. An external-app installation fee calculator

• What: A tool that shows expected fees and the amount remaining per installation based on successful external-app installations and app classification.
• Who: A mobile game publisher considering whether to let people download a separate game or app from its Play app.
• Why now: Installation fees differ between standard apps and games, and even 10,000 installations can amount to tens of millions of Korean won.
• First screen: Input fields for app type, expected successful installations, and payment revenue, with fees and profit or loss changing immediately.

3. A refund and dispute evidence vault

• What: A service that puts the timeline from link click through payment, access entitlement, and refund on one screen, then exports it as evidence files.
• Who: A customer-support team at a Korean content app handling US subscription cancellations and unauthorized-payment claims.
• Why now: When an operator takes payments directly, it must explain refunds and customer disputes rather than relying on the app marketplace to do so.
• First screen: Search by transaction number to see click, authorization, access, and refund in order, alongside any missing records.

4. A rules calendar for multiple apps

• What: A service that manages reporting deadlines, missing records, and the active version of the rules by country and app.
• Who: An app maker or operations agency managing payment operations for apps in Korea, the United States, and Japan.
• Why now: Even within Google Play, link formats and reporting timing differ across Korea, the United States, and Japan, making a single checklist difficult to use.
• First screen: A country-by-country app list with the next deadline, unresolved count, and most recent rule-change date shown like traffic lights.

Why this matters where you are

If your product uses payment links outside an app store, trace one purchase from click to refund and check whether its records can be explained from a single place. Rules, fees, and reporting deadlines may differ in your market, but the underlying operational issue is the same: payment, subscription, and refund systems can each hold a different version of the transaction. A small ledger test can reveal where those records stop connecting.

One thing to check in 30 minutes today

Ask an app operator who offers or is preparing web payments for US users to trace one recent transaction and one refund from start to finish. If this requires moving across three or more screens or files, or if they cannot explain within 10 minutes which click created the transaction, a record-ledger service is worth testing.