App_fee_money with Terminal API for Japan (JP) sellers in 2026

Questions
,
1

Is app_fee_money supported with the Terminal API (CreateTerminalCheckout)
for sellers located in Japan (JP)?

A forum reply from 2024-07 stated that collecting app_fee_money with the
Terminal API was not supported outside of the US at that time, and there
was a 2023 case where an AU seller received INVALID_LOCATION
(“app_fee_money is not supported in the merchant’s location”).

The “Collect Application Fees” documentation lists a JPY threshold (¥600),
but does not state whether the Terminal API is included for JP.

  1. Is it supported for JP in 2026?
  2. If yes, does the developer account need any specific activation or
    approval to receive application fees from JP sellers?
  3. If no, is there a supported way for a platform to collect a fee on
    in-person card payments in Japan?

Thanks.

3

It should be allowed, but I would recommend testing a simple case in sandbox or production to verify before a larger build out.

There’s no technical enablement step, but in Japan, Square may review how app fees are used. Fees should pay for your application’s service, not take a recurring cut of the seller’s sales. These are the requirements:

  • The fee has to be collected by a Square account based in Japan, and the fee currency must be JPY to match the seller. A US/USD developer account can’t collect fees from JP sellers, so you’d need a JP Square account and use its application ID for JP sellers (International Development).
  • Both your JP account and the seller’s account must be able to process card payments.
  • Sellers must authorize your app through OAuth with PAYMENTS_WRITE_ADDITIONAL_RECIPIENTS. If you add that scope later, sellers have to re-authorize. You can check this with GET /oauth2/token/status (Collect Application Fees).
5

Thank you, that’s very helpful.

Could you clarify what would be considered acceptable use in Japan?

Our model: we provide a full restaurant system (self-order kiosk, POS,
kitchen display, attendance, cost management) to merchants with no monthly
charge. Instead, we charge a system usage fee on each transaction that is
processed through our system. Merchants can alternatively choose a flat
monthly plan.

The fee applies only to transactions processed through our application —
not to the merchant’s sales in general.

Would this be considered “paying for the application’s service”?
Or would the per-transaction structure itself be a concern, regardless of
the service provided?

6

That is only a soft limit you’d want to make sure you don’t get flagged by a seller. The only hard limits are documented here

7

Thanks again for the guidance. We tested in the sandbox with a JP seller test account:
a Terminal API checkout of 1,000 JPY with app_fee_money of 20 JPY completed successfully,
and the payment shows app_fee_money 20 JPY and processing_fee 33 JPY.
The seller’s sales summary also shows the 20 JPY deducted as “Default Test Account”.

Follow-up questions:

  1. In the sandbox, are payouts (Payouts API) generated for the developer’s default test account?
    We see 0 payouts so far. If not, is there any way to verify in the sandbox that the app fee
    actually reaches the developer account?
  2. In production, will app fees collected from JP sellers appear in the JP developer account’s
    payout entries with type APP_FEE_REVENUE?
  3. If the seller account and the developer account are the same Square account,
    what happens when app_fee_money is specified? Is it rejected, or ignored?
8
  1. Sandbox payments should generate payouts. You can check with ListPayouts by passing a location_id. Another way is to check seller-side with GetPayment and confirm app_fee_money is on the payment. If you are taking payments as the default test account through your own app, the app fee will be rejected (see 3), so they need a separate seller test account that authorizes the app through OAuth.
  2. Payout entries do include app fee revenue: ListPayouts → ListPayoutEntries itemizes app-fee revenue against each payment_id . The entry type is APP_FEE_REVENUE (ActivityType).
  3. Same account: The request is rejected, not ignored. A fee of 0 skips this check on Terminal checkouts.
9

Thanks for the detailed answers.

We are passing location_id (the default test account’s only location) to ListPayouts,
but it still returns 0 payouts about a day after the payment.
The seller-side GetPayment shows app_fee_money 20 JPY on the payment.

  1. How long does it take for a sandbox payout to be created?
  2. Does the default test account need a linked bank account or a payout schedule
    for payouts to be generated in the sandbox?
10

Thanks. We found that another Square employee answered in September 2026 that
app fees are not fully supported in the sandbox and the end-to-end flow can’t be
seen without moving to production
(Sandbox OAuth + app_fee_money: where should the application fee appear?).
The sandbox overview also states that Balance and application fee reporting
are not supported.

Could you confirm that APP_FEE_REVENUE payout entries are not generated in the
sandbox, and that the only way to verify the full flow is a small test in
production (checking ListPayoutEntries a few hours to a day after the payment)?