The ¥1 Authorization Ban: Three Response Patterns by Payment Provider

The ¥1 authorization used only to confirm that a card works is going away under a brand rule change. What a merchant has to do, though, splits three ways depending on the payment provider under contract. This article covers which of the three applies to a site, and how to build the state that lets you compare before and after the switch under one definition.

TL;DR#

• What is prohibited is an authorization hold whose purpose is a validity check. A ¥1 payment does not become unusable across the board
• A merchant's task falls into one of three: the payment provider rewrites the amount on its side, the transaction type changes to a validity check, or the amount changes to ¥0
• The start dates differ — September 28 for Kuroneko Web Collect, September 30 for GMO Payment Gateway, SMBC GMO PAYMENT and Veritrans — and the ZEUS table is written as the charging method from October 1 onward
• None of the announcements go as far as saying which of your own processes is in scope. Where a ¥1 authorization is being called is known only on the merchant's side
• A validity check runs before the purchase, so the effect of the switch shows up in neither revenue nor order count

1. The Same Rule Change Splits Merchants Into Three Different Tasks#

To start with the conclusion, a merchant's task falls into one of three: the payment provider rewrites ¥1 to ¥0 on its side, the transaction type changes, or the amount changes to ¥0. What divides them is the payment provider under contract.

Suppose one inquiry arrives in the latter half of October saying a card cannot be registered. Unless you recorded what switched over on the payment side at the end of September, tracing back how long it had been happening gets no further than the day the inquiry arrived. There is one thing to confirm during September: which of the three the payment provider under contract falls into.

Start dates and merchant tasks by payment provider

The ZEUS announcement is the only one that writes the date two ways. The body says the start is planned for around September 2026 and that the detailed schedule will be announced again once fixed. The heading of the table under change item 4, meanwhile, reads "Charging method (from October 1, 2026)"[1]. Rather than collapsing the two into a single date, keep both on record as they are. The brand rule itself takes effect on October 1, 2026[5], and each company's deadline sits just ahead of it, which is why they cluster at the end of September.

On Kuroneko Web Collect, even if a merchant sends an amount of ¥1, the payment provider rewrites it to ¥0 and runs the authorization[3]. But an automatic rewrite does not necessarily mean there is no work for the merchant. The same document states that where an integrated cart is in use — with some carts excepted — no individual action is required, while for self-built sites, if a small-amount authorization is being run at an amount other than ¥1 for the purpose of a validity check, the merchant is asked to change it to ¥1[3]. The rewrite covers only ¥1, so running it at ¥2 or ¥10 falls outside its scope.

One more point is easy to misread. What was prohibited is not a ¥1 payment itself. In the ZEUS table, a small-amount ¥1 authorization becomes unavailable only for an authorization-hold payment, and it remains possible with an immediate capture[1]. The GMO Payment Gateway and SMBC GMO PAYMENT announcements likewise write the target of the prohibition as an authorization hold not aimed at a sale[2][4].

The change under the same brand rule where the window for capturing an authorization was cut to 25 days works by a different mechanism. There, the period over which credit can be held got shorter and expired authorizations are cancelled automatically. Here, the means of running a validity check is itself becoming unusable.

2. No Announcement Says Which of Your Screens Runs the Check#

To start with the conclusion, what an announcement can answer goes as far as whether the payment provider under contract leaves you work. Which scene on your own site calls a ¥1 authorization is written in none of them.

ZEUS asks merchants to check whether they are running small-amount authorizations[1]. GMO Payment Gateway and SMBC GMO PAYMENT attach a condition — if you are running an authorization hold at a small amount such as ¥1 — and then explain the transaction type change[2][4]. Veritrans phrases it as a request to change the amount to ¥0 where a small amount is explicitly specified on a validity check[5]. In all of them the subject is the merchant, and which processing on which screen that refers to is not written.

Announcements have come from the cart side on the same dates. Color Me Shop writes that from September 30, 2026, authorization-hold processing for a validity check not aimed at a sale is prohibited, and directs merchants to use the dedicated validity check tools each payment provider offers[6]. Seen from the cart side too, what comes next is decided by the payment provider under contract.

The starting point of this branch is not the announcement but your own site. Where there is a scene that runs a validity check, confirm in the implementation which screen calls that processing.

What makes this harder is that the switch itself happens before the purchase. Measured revenue is posted at the moment of the order, so this change is reflected in neither revenue nor order count. Because it is not reflected, nothing is left behind as a clue if something changes after the switch.

The other change arriving on the payment side in the same period was covered in the end of partial captures and partial refunds. That one concerns how the amount is handled after the purchase. Diagnosing a sudden spike in cart abandonment deals with fraudsters testing cards through small-amount payments. The words "small-amount authorization" are the same, but the party running it is reversed.

3. Clustered Start Dates Leave More Than One Candidate Cause in October#

To start with the conclusion, because the start dates cluster between September 28 and October 1, more than one candidate cause stands up at the same time when something changes in October.

In order: on September 28 the rewrite begins in the Kuroneko Web Collect production environment[3]. On September 30 an authorization hold not aimed at a sale is prohibited at GMO Payment Gateway and SMBC GMO PAYMENT[2][4], and the same end of September is Veritrans's merchant response deadline[5]. The ZEUS table is written as the charging method from October 1 onward[1].

Changes unrelated to validity checks land in the same period as well. At GMO Payment Gateway and SMBC GMO PAYMENT, cancellation processing for transactions past the capture deadline starts on October 2[2][4]. When a figure moves in October, the material for separating the validity check switch from a past-deadline cancellation from a seasonal swing can only be prepared during September.

What to prepare is a state in which before and after the switch can be compared under the same definition. The object of the comparison is not revenue. A validity check runs before the purchase, so a visitor who stops there is a purchase that never happened, reflected in neither revenue nor order count. The place to look is the count of people who moved past the screen that calls that processing. Three things to decide: the planned switch date, the URL of the screen that calls the validity check, and the periods before and after over which that screen's trend will be compared.

The way of thinking about continuing a before-and-after comparison across a change in specification is in carrying measurement across a cart migration, and the procedure for getting the purchase itself onto measurement is in tracking ecommerce purchases.

What the payment provider's admin can confirm goes as far as whether that processing went through. That an authorization was established at ¥0 can be confirmed in the transaction lookup[3]. How many people moved past the screen that calls that processing is displayed nowhere on the payment side.

RevenueScope solution

RevenueScope lets a page-by-page trend be compared under the same definition. The page breakdown tab displays views, the prior-period change in views, and average dwell time in seconds for each page. Specify the period as before and after the switch date, and the same page can be compared on the same metrics across the two. Page names are shown on two lines as title and path, so the screen that calls the validity check can be picked out from the list.

One illustrative page breakdown for fictional Store A

Note: the table above is one example constructed for the explanation. What the demo screen displays is the sample data of the sample ecommerce store, updated daily, so neither the page names nor the figures will match.

The gap in views between the top two pages is about 4%, and the prior-period change differs by 1 point. Comparing those two before and after the switch date does not establish that anything changed. What separates the judgment is something absent from this table: the number of times a visitor on that page moved on to the next action.

RevenueScope measures arbitrary actions other than purchases. Adding one data-rs-goal attribute to the element you want to measure is all it takes, with no code and no tag setup. Put the attribute on the button that calls the validity check, and the number of times that button was pressed is displayed page by page. The count is not unique, so the same person pressing three times is counted as three. Goal events and session revenue sit on the same data, so they can be matched up afterward. On screen they are displayed separately.

Add one attribute during September, and before and after the switch date you can compare views, prior-period change, and the number of times that button was pressed for the same page under the same definition.

FAQ#

Frequently asked questions#

Q. Will ¥1 payments become impossible from now on?

A. Not impossible across the board. In the ZEUS table, a small-amount ¥1 authorization becomes unavailable in the case of an authorization-hold payment, and it remains possible with an immediate capture[1]. What is prohibited is an authorization hold not aimed at a sale — that is, processing whose only purpose is a validity check[2][4].

Q. Where do I check whether my site is in scope?

A. The starting point is the announcement from the payment provider under contract, but what that tells you goes only as far as whether there is work to do. Which processing on which screen calls a validity check is not written in the announcements, so check the implementation of your own site.

Q. If the payment provider rewrites the amount to ¥0 automatically, is there nothing for the merchant to do?

A. Not necessarily. In the Kuroneko Web Collect document, self-built sites are asked to change a small-amount authorization being run at an amount other than ¥1 to ¥1. Only ¥1 is covered by the rewrite[3].

Q. Can the effect of the switch be confirmed in a revenue report?

A. It cannot. A validity check runs before the purchase, so a visitor who stops there is reflected in neither orders nor revenue. The place to look is the count of people who moved past the screen that calls that processing.

Summary#

The work to finish during September is not a check but securing a baseline. First, record the planned switch date for the payment provider under contract. Kuroneko Web Collect is September 28[3], GMO Payment Gateway and SMBC GMO PAYMENT are September 30[2][4], Veritrans's merchant response deadline is the end of September[5], and the ZEUS table is written as the charging method from October 1 onward[1].

Next, decide the comparison periods around that date in advance. Fix the width — three weeks before and three weeks after, say — and you avoid attaching conditions after the fact when something changes in October.

Finally, prepare something other than revenue as the object of the comparison. Secure one metric during September that can be followed under the same definition across the switch date, and the changes in October can be separated one by one.

References#

• [1] ZEUS "Notice of specification changes accompanying the brand rule change" (2026)
• [2] GMO Payment Gateway "[Spec] Changes to transaction specifications accompanying the credit card brand rule change (capture deadline change and others)" (2026)
• [3] Yamato Transport "Kuroneko Web Collect credit card payment: requests to merchants accompanying the request from the international card brands" (2026)
• [4] SMBC GMO PAYMENT "[Spec] Changes to transaction specifications accompanying the credit card brand rule change (capture deadline change and others)" (2026)
• [5] Veritrans "Notice of credit card payment transaction specification changes accompanying the brand rule change" (2026)
• [6] Color Me Shop "[Important] Changes to credit card payment specifications accompanying the VISA and Mastercard rule change (updated 7/14)" (2026)