Payment and subscription setup for a global SaaS — a common pattern for handling multiple gateways

For subscription SaaS, payments don't end with a single gateway. The same user might pay from a mobile app, the web, or abroad, and each channel has different policies, fees, and settlement cycles. If you launch with just one channel, problems pile up one after another: "conversion is low," "refunds don't work," "settlement is slow." This article lays out the universal setup pattern for running three channels at once — local payments, global cards, and in-app purchases.

Three channels — by category

• Local payment gateway — the channel that accepts cards and simple payments in the user's home region, in their local currency. Highest conversion. Short settlement cycle and deposits in local currency.
• Global card processing service — the channel that lets overseas users pay in foreign currency with their own cards. Standardizes currency conversion, tax handling, and multinational receipts.
• In-app purchase abstraction tool — a layer that lets you manage mobile-OS in-app purchases (IAP) from a single console instead of handling them directly in the app. Standardizes refunds, family sharing, and grace periods.

When one SaaS runs all three channels, from the user's perspective it becomes "I can pay in a familiar way anywhere," while from an operations perspective you have to deal with a different console and different settlement for each channel. The universal pattern is designed to reduce this complexity.

Why run three channels at once

Using just one channel brings the following problems.

• Global card processing service only — an English-language checkout cuts conversion in half for users in some regions. There are large markets that expect options like local-currency pricing and interest-free installments from domestic card issuers.
• Local payment gateway only — overseas users try to pay in foreign currency and fail. Currency conversion and tax handling are also inconsistent from gateway to gateway.
• In-app purchases only — users who sign up on the web have no payment path. The mobile-OS commission (usually 15–30%) is multiplied against your entire revenue.

Fees — headline rate vs. real burden

Fee structures by channel fall into roughly the following ranges (specific figures vary by market and over time).

Key insight — mobile in-app purchases have the highest headline fee, but if you convert the cost of writing your own SDK (2 weeks + debugging refunds and family sharing) into an hourly rate, the 1% of an in-app purchase abstraction tool breaks even within six months. The decision to build it yourself isn't too late to revisit once revenue passes a certain scale.

Settlement cycles — the real difference in cash flow

• Local payment gateway — settlement on the payment date + 3–7 business days. Fastest and simplest. Deposited directly in local currency to a domestic bank.
• Global card processing service — the first revenue waits 7–14 days, then settles weekly/daily afterward. To receive remittances in foreign currency at a domestic bank, you need a foreign-currency account.
• In-app purchases — the platform settles once a month (previous month's revenue, around the middle of the following month). The first two months are the period where "you can see it selling but nothing lands in the bank account."

As a result, a new SaaS is safest starting with two to three months of operating cash on hand. Revenue accrues daily, but deposits come in on different cycles for each channel.

Unified entitlement key — the heart of the setup

When three channels run at once, the same entitlement must apply to the same user regardless of where they paid. The flow of a user buying on the web and using on the app has to feel natural. The universal setup pattern is as follows.

1. Define entitlement keys independent of the payment channel — e.g., stash_pro, stamp_premium, allinone. No matter which channel the payment comes through, it maps to the same key.
2. Payment channel → entitlement key mapping table — a conversion function that normalizes the different product codes (SKUs) from each channel into entitlement keys.
3. Central entitlement check — the app and server ask only about the entitlement key, regardless of channel. If the entitlement key exists, the user passes; if not, they go to the payment screen.
4. Update via webhooks — payment success, renewal, refund, and expiration events update the entitlement in the central user table.

The greatest value of this pattern is the user experience. Flows like "I paid on the web but it didn't unlock in the app" disappear. From an operations perspective, when a new channel is added, you just extend the entitlement key mapping and you're done.

Legal and tax — the part SaaS often overlooks

Adding a single payment channel is 1–2 weeks of code, but the legal and tax work that follows is usually longer. The items you need to handle across all regions are as follows.

• Business registration · mail-order/e-commerce filing — most SaaS also falls under the mail-order category. Handling it before your first sale removes the risk of penalties.
• Purchase safety · escrow — in some markets, enrolling in purchase-safety protection must precede payment processing for the filing to go through.
• VAT · consumption tax — apply the domestic rate to domestic residents. Apply a zero rate or a reciprocal treaty to overseas residents. Global card processing services usually offer an automatic VAT calculation option.
• State your receipt and refund policy — if you don't state your refund policy on the payment page and in the app, you're at a disadvantage in consumer disputes.

Since the detailed rules differ by region, sorting things out once with a local tax accountant and legal advisor before your first payment pays off again and again.

If you have to "pick just one"

• B2B SaaS with a large average transaction value — a single local payment gateway. Conversion and settlement speed matter most.
• B2C mobile app — a single in-app purchase abstraction. Effectively required by platform policy.
• Global-first from the start — a single global card processing service. Enter many markets with one piece of infrastructure.

In practice, the common flow is to start with a single channel and then add another "because conversion is low" or "because of store policy." Starting with one channel first → validating revenue → adding the rest is the safe approach.

STA's payment setup

The STA integrated app (calendar, mail, memo, to-do — four tabs) and the Stats web SaaS follow the universal pattern described above.

• Web payments — automatically routed to a local payment gateway or a global card processing service depending on the region.
• Mobile in-app purchases — unified through an in-app purchase abstraction tool. Webhooks update the central entitlement table.
• Unified entitlement keys — sta_pro, sta_pro_yearly, sta_team, stats_premium. No matter which channel you bought through, the entitlement check uses the same key. Subscribers to the four existing apps (Stamp · Stash · Stanza · Stage) are automatically migrated to STA Pro, and if their previous price was lower, it is kept as is.

Wrapping up

SaaS payments have a structure of "1 week of tech, 1 month of legal, settlement, and operations." If you sort out the universal pattern once before setup, the flow stays simple even as channels multiply. Absorbing channel complexity with a single unified entitlement key — that's the safest way to handle multiple gateways.

In the STA integrated app, the four tabs are bundled under one payment and one entitlement. Start free with no card required, and unlock all four tabs with STA Pro at ₩9,900/month (or ₩99,000/year).