A Tool for Connecting Apple Payments and Alternative Payment Records Is Opening Up

Payment options are expanding, and operational responsibility has moved to the app

Apple (애플) revised its app business terms for the European Union on August 18, 2026, with the changes taking effect on October 1. It removed its previous fee based on install counts and switched to a percentage of transaction value based on where an app is distributed and where payment is taken.

For standard transactions, the fee is 26% when an app uses Apple payments inside the app marketplace, 20% when it uses another in-app payment method, and 15% when it links to a web purchase. Digital transactions for apps distributed outside the app marketplace carry a 5% fee. On a KRW 10,000 pre-tax sale, that is KRW 2,600, KRW 2,000, KRW 1,500, and KRW 500 respectively, though other payment methods also add payment-processing and tax-handling costs.

In the European Union app marketplace, an app can now present Apple payments, another in-app payment method, and a web purchase link together. But if Apple payments are offered alongside them, they cannot be displayed less prominently than the other payment methods, and the chosen combination of payment methods must remain in place for 12 months. One choice can therefore lock in an operating model for a year.

The app business is responsible for taxes, refunds, subscription management, purchase verification, and customer support for orders received through other payment methods. Transaction data must be reported to Apple within 15 days after the end of each month, and the business must manage records not only for successful payments but also renewals, refunds, cancellations, and payment reversals.

A web purchase link can tie a transaction made within seven days of a click to fee calculations, so the click time and order time must also be connected. Web purchase links are restricted in apps for children, and a process involving a guardian is required when alternative payments are presented to minors. This is not simply a matter of adding a payment button. It changes screens, order records, user age handling, and refund records together.

The work breaks down after the payment

Consider Jihyun, who manages European subscriptions for a 12-person South Korean language-learning app. Until now, the app has sold monthly and annual subscriptions through Apple payments. Jihyun checks revenue and subscription status in Apple’s management dashboard, then reconciles them with the company’s books.

Even in that setup, customer accounts need to be connected to Apple orders, but there is one starting point for payment records. When a customer says a purchase is missing, the team checks whether the Apple purchase happened and whether paid access was unlocked in the app. Refund and subscription-cancellation guidance also follows a relatively single path.

Once Jihyun offers Apple payments and another payment method together, the flow splits. The team has to identify which button the customer selected, find the order number in the payment processor dashboard, find the same person again in the company’s customer list, and confirm that paid access was unlocked. Finally, it must determine whether the transaction belongs in Apple’s reporting and copy it into a separate record.

The break becomes clearer with refunds. A support agent receives an inquiry and passes it to Jihyun. Jihyun identifies whether it was an Apple payment or another payment method, then issues the refund in the relevant dashboard. The team must then revoke app access and update both tax records and Apple fee-reporting values, entering the same order number and amount repeatedly across several screens.

Purchase verification does not automatically stay connected either. A payment processor may show a successful charge while app access was never unlocked, or learning content may remain open after a refund. A support agent collects the payment receipt and passes it to operations, which asks a developer to check the account status.

At month-end, the team must reconcile Apple records, other payment records, refund lists, tax materials, and company books. If it used web links, it must also check whether each purchase happened within seven days of the click, and separate subscription renewals from failed payments. When these sources use different names and order numbers, the work ends up in spreadsheets and manual matching.

Some decisions still require people. Someone must decide which payment method to recommend, whether to accept an exceptional refund, how to block a suspicious transaction, and how to report taxes in each country. A new tool would not make those decisions for them. It would connect the same order scattered across systems into one row and flag missing follow-up work.

Alternative marketplaces also had to connect payment and access

AltStore PAL (알트스토어 PAL) is an alternative iPhone app marketplace launched in the European Union. Its operator has said it takes payments through Stripe and connects subscriptions and app access through RevenueCat, while listed developers can choose their own payment provider. It later expanded its official distribution scope to Japan and Brazil.

In this structure, AltStore handles app discovery, installation, and updates, while payment is processed through a separate tool chosen by the developer. Because the marketplace and payment are separated, connecting a buyer to the app features they purchased became a product in its own right.

Aptoide (앱토이드) began trial operations of an alternative iPhone marketplace in the European Union in 2024 and later expanded access. When developers add Aptoide’s payment tools to an app, they can handle product lookup, payment confirmation, and server verification in one flow. Under its official terms, 80% of payment value goes to the developer.

Aptoide did not provide only a marketplace. It also bundled payment-confirmation tools. Its product design shows that when app distribution and payment are opened separately, order verification and access provisioning can break in the gap between them.

MacPaw’s Setapp Mobile (셋앱 모바일) offered more than 50 iPhone apps through a single subscription in the European Union. Because it shared subscription revenue with developers based on the apps users actually opened, it had to keep one payment record connected to usage records across multiple apps.

Setapp Mobile ended on February 16, 2026. The company said that changing and increasingly complex business terms did not fit its model. This shows that the operational work of continuously reconciling subscription records, usage-based allocation, and platform terms can outlast the technology required to open an alternative marketplace.

Four things to build from here

1. Order record reconciler

• A service that finds the same order across Apple, payment processors, customer accounts, and accounting records, then connects it into one row.
• It is for South Korean education, fitness, and content apps with European subscribers but only one or two people dedicated to payments.
• As apps can show payment methods together, one customer’s records have started to split across several management dashboards.
• The first screen shows orders with mismatched amounts or statuses, orders where access was not unlocked, and days remaining before a reporting deadline.

2. Refund workflow guide

• A service where a support team enters a customer email or order number, finds the payment path, and sees the follow-up actions in order.
• It is for customer support teams at mobile games that run Apple payments and their own card payments together.
• As app businesses take responsibility for refunds and purchase verification for other payment methods, manual work between support and payment screens has increased.
• The first screen places payment cancellation, access revocation, tax-record updates, and whether Apple reporting needs to be updated side by side with a customer search field.

3. Payment screen checker

• A service where a team uploads an image of a payment screen and receives a checklist for Apple payment display size, alternative payment buttons, web links, and procedures for minors.
• It is for small South Korean subscription apps preparing for a European launch without a local operations manager.
• Apps can now place several payment methods together, but each screen must be checked for equal display and age-based restrictions.
• The first screen asks four questions: app type, user age, distribution route, and payment-method combination.

4. Distribution model decision calendar

• A service that puts fees, reporting dates, the 12-month commitment period, and preparation work for in-marketplace and outside-marketplace distribution into one schedule.
• It is for South Korean app operators with European revenue who have not decided whether to expand into alternative marketplaces.
• The outside-marketplace fee has changed to 5%, but a real choice also requires considering installation flows, payment-processing costs, and refund operations.
• The first screen asks for product price, subscription period, current distribution channel, and expected payment path, while showing missing costs separately.

Why this matters where you are

Wherever you operate, check whether new payment choices split records between your marketplace, payment processor, customer support system, and accounting tools. The fees, reporting rules, and restrictions will differ by market and platform. Follow one recent refund from start to finish to identify the handoffs a tool could connect.

Follow one case today

Ask one operator of an app with European customers to share their screen and trace one recent refund from beginning to end. If they open three or more management screens in 30 minutes, or copy the same order number more than once, a tool connecting those gaps is a strong first product candidate.