The Operations Tools That Clean Up After External Payments

External payments create follow-up work

Google Play’s External Content Links program for the US is an optional program that lets app users go to a web payment page or an external app-download page. An app made by a Korean company can also participate if it shows links to users in the United States and its territories.

From October 1, 2026, participating developers must record covered transactions and successful external app downloads, then pay the related fees. Google says the deadline to report successful downloads and pay the fees is February 1, 2027.

The records are not limited to paid orders. They can include new purchases completed within 24 hours after an external link is clicked, subscription renewals, top-ups, product changes, zero-value transactions created through free trials, and external app installations.

There is more than one fee. According to Google’s guidance, auto-renewing subscriptions are charged 10%, while other digital goods are generally charged 10–20% depending on the conditions. External app installations cost $3.65 per game installation and $2.85 per general-app installation. At the exchange rate used in the original calculation, that is about KRW 4,830 and KRW 3,770, making 1,000 installations worth several million won.

Payment happens outside the app, but Google’s involvement does not end there. Operators need to reconcile successful payments, refunds, subscription status, the features actually unlocked in the app, and the records sent to Google.

Reconciling records is harder than building a checkout page

Consider a hypothetical first customer: a Korean-language learning subscription app with six employees. It has users in the US, has just started taking external web payments, and has a representative, two developers, and one person handling customer inquiries.

Today, the team downloads order files from its payment service provider, pastes them into a shared document, matches them to app member IDs, and unlocks paid features. At month-end, it organizes the same data again to identify transactions to send to Google and calculate expected fees.

A refund splits the work again. After returning money through the payment provider, the team must close the user’s entitlement in the app and reconcile both the original transaction sent to Google and the refund record. Orders that change state—such as free trials, partial refunds, or a retry after a failed payment—can easily turn one row into two or three.

A small operations tool could first store a pair of identifiers: a one-time transaction ID created from the external link and the payment order ID. Once payment is complete, it could send the data through Google’s required automated reporting channel and save the acknowledgment response.

Rather than reviewing every order, the operator would see only the problematic ones: paid orders with no member ID, refunded orders with an active entitlement, and orders whose reporting time has passed or whose fee differs from the estimate.

Some work still requires human judgment. The operator must decide whether a user falls within the US scope, whether a product qualifies as a digital good, and how to handle a disputed refund. The tool should not make those decisions for them. It should bring the order record and its change history into one place so they can decide.

The first ten prospects could be small Korean Android subscription-app and mobile-game teams with US revenue that already run, or are considering, external payments. Start with the assumption that they can be found through mobile app operator communities, customer communities for payment providers and subscription-management tools, and existing clients of app development agencies. Prioritize teams that currently combine shared documents, downloaded payment-provider files, internal admin screens, and temporary tools built by developers.

Elsewhere, payment and entitlements are being managed together

Poland-based game company Huuuge Games used Appcharge’s web store and out-of-app payment links for US users. Appcharge manages not only the payment screen but also taxes, refunds, payment disputes, and transaction data. Huuuge expanded to four custom web stores and two games with payment links.

According to Appcharge, Huuuge’s share of direct out-of-app revenue rose from 10% in the first quarter of 2024 to 30% in the third quarter of 2025, then reached 34–35%. These are supplier-reported figures. They combine web stores with US iPhone and Android payments, so they cannot be treated as results from Google links alone.

GRTV, a US horse-racing information subscription app, used RevenueCat to connect web payments with in-app paid entitlements. After a user subscribes on the web using a card or a simple payment method and returns to the app, premium features are unlocked on the same account. The app manages in-app and web-payment status in one place.

RevenueCat says 76% of GRTV’s US revenue came from web payments. This is an iPhone example rather than Google’s reporting model, but it shows that per-member entitlement records still need to reconcile even when payment happens elsewhere.

FastSpring provides a public example for US Google Play external-link payments. The flow creates a one-time transaction ID in a game, takes an external payment, confirms payment success, grants game currency, and reports the transaction to Google.

This is a test implementation showing how the connection works, not a customer-results case. Even when a payment provider is involved, the developer retains its own Google Play account and reporting responsibility. That suggests a final confirmation screen and missing-record alerts could be a separate product.

Four small ways to start here

1. External transaction inbox

This service matches payment-provider orders, app members, and Google reporting records, then shows only missing transactions. It is for education, fitness, and productivity app operators with US subscribers, three to ten employees, and no dedicated finance staff.

It is needed now because reporting obligations have begun and records can include free trials and renewals. The first screen should show three lists: “Paid but unreported,” “Reported but no member,” and “Refunded but entitlement active,” along with the deadline.

2. External payment fee preview

This service takes last month’s order file and compares expected revenue after Google fees, payment-provider costs, and refunds under external links. It is for subscription-app operators or game operations leads who have not decided whether to add US external payments.

Allowing external payments does not mean Google fees disappear, so a decision based on revenue alone can misread profitability. The first screen should include fields for product type and expected order volume, the estimated difference between the current model and external payments, and the fee rules used in the calculation.

3. Refund and entitlement reconciler

This service checks whether a single refund has completed payment cancellation, in-app feature removal, and Google refund reporting. It is for dating, fitness, and content apps with monthly subscriptions and partial refunds, where only one or two people handle customer inquiries.

For external payments, the responsible party for refunds and customer support must be defined separately, and the program and supplier contracts must be checked. Returning money while leaving the entitlement or reporting record in place can lead to losses and further inquiries. The first screen should put today’s refunds in processing order and show completion markers beside each order for “Payment cancelled,” “Entitlement removed,” and “Reported to Google.”

4. Successful download verifier

This service identifies people who clicked an app’s external download link and completed installation within 24 hours, then turns that into reporting data. It is for operators distributing games, security tools, or enterprise apps through their own app store or a separate installation file.

Each successful installation carries a fixed per-install fee and must be reported as a zero-value one-time transaction, so counting clicks is not enough. The first screen should show “Link clicked,” “Installation consent,” “Installation complete,” and “Reporting complete” in sequence, with access to the cases that dropped off at each stage.

Reconcile one real ledger today

Ask one Android app operator with US revenue for a 20-minute screen share. Choose just five recent orders and reconcile, one by one, the payment-provider record, the app entitlement, refund status, and Google reporting status.

If two or more of the five cannot immediately be connected by ID or status, or if the operator spends more than 30 minutes reconciling them manually each month, there is a reason to test a first product. If everything is already completed automatically in one screen, that team is not the first customer.

Why this matters where you are

If your market is opening more paths to web or external payments, check who still owns transaction reporting, refunds, and entitlement updates after payment leaves the app. The fee rules, platforms, and legal scope may differ from the US Google Play program described here. The practical action is the same: trace a small set of real orders across payment, access, refunds, and reporting before building another checkout flow.