A size exchange or a single out-of-stock item, and you return part of the order amount. The partial capture and partial refund used for that reach their scheduled end of support in SB Payment Service (SBPS) credit card payments on September 30, 2026. From October 1, the amount posted as revenue equals the authorized amount. The same update also adds an amount change request. This article separates what is settled from what is still unstated.
Contents
TL;DR#
- What the notice lists as reaching end of support is "partial capture, partial refund," with a date of September 30, 2026
- From October 1, 2026 the amount specified in a capture request becomes "the same as the authorized amount." The capture request itself can no longer specify a reduced amount
- The same update adds a function ID called "amount change request," but the notice does not state a procedure for using it in place of partial capture and partial refund
- With no procedure stated, how to close out the month in which a refund is issued is left to each merchant
- Site-side revenue is posted at the moment of the purchase event, so revenue stays in the report even after a refund is issued on the payment side
1. The Notice Settles Two Things#
What the notice settles is the function and the date on which it ends, plus the amount posted as revenue from October 1, 2026.
Hearing that something ends in late September, the first screen most people open is the payment provider admin. That screen shows the functions available today, and the October treatment cannot be read from it. The settled content sits in the notice.
The SB Payment Service (SBPS) update history was updated on June 1, 2026. In the credit card function list, "partial capture, partial refund" for one-time billing and specified capture carries the note "scheduled end of support 2026/9/30" [1]. The constraints on the partial refund request carry the same date, stated as scheduled end of support on September 30, 2026 [1].
Partial capture posts only a portion of the authorized amount as confirmed revenue. The authorized amount is the sum reserved with the card issuer at the time of the order. Partial refund returns only a portion of the confirmed revenue. Both are used where the amount falls after the order: a size exchange that produces a difference, or one item out of stock among several.
The second settled point is the capture request setting. The notice states that from October 1, 2026 the setting changes to specifying the amount posted as revenue, which is the same as the authorized amount [1]. From October 1, the amount specified in a capture request equals the authorized amount.
What stands out in this chart is that the value converges to a single point on the right. Through September 30, a smaller amount could be specified within the authorized amount. From October 1, the only target is the authorized amount itself. The word "specify" remains, but there is one value to choose.
The same June 1, 2026 update also revised the capture deadline and the cancellation window for one-time billing. For specified capture it reads "up to 25 days from the purchase request processing date, inclusive (approximate)" [1]. That 25-day figure is covered in the 25-day card authorization rule. That article is about the deadline for confirming revenue; this one is about the amount confirmed.
2. No Replacement Procedure Is Stated#
What to do in place of partial capture and partial refund is not stated in the notice.
The same June 1, 2026 update adds a function ID called "amount change request" to the credit interface spec. An "amount change window" was also added to the one-time billing base spec [1]. The function that ends and the function that was added appear in the same update.
The notice, however, does not state a procedure for using the amount change request in place of partial capture and partial refund. Mapping the added function onto the ending one sits outside what the notice states.
This is not something overlooked; it is the fact that nothing is stated. With no procedure announced, how to close out a size exchange or a partial shortage from October 1 onward is left to each merchant.
Because rereading the notice will not surface the answer, the work splits into listing and confirming. First, open the refund records for the past three months and list the situations where a partial refund was used: size exchanges, partial shortages, shipping fee cancellations, partial cancellations across several items. Once the count and the scale of the amounts are visible, the October load can be estimated.
Next, confirm how many of those occur per month. A handful per month keeps the load contained, but if they occur daily, deciding the procedure before October 1 becomes the task.
Last, ask the payment provider you contract with about operations from October 1. That is the point of this article: the notice does not carry the answer.
3. A Refund Does Not Remove Revenue Already Posted#
Site-side revenue is posted at the moment of the purchase event, so revenue stays in the report even after a refund is issued on the payment side.
Site-side analytics aggregate revenue from the event sent when a purchase completes. A refund is processed on the payment side, so no event is sent to the site side.
As a result, if a partial refund against an August order is issued in September, August revenue stays as it is and September revenue does not fall. Even once partial refunds are unavailable from October 1, this posting moment does not change.
Patterns where the posted count itself drifts are separate from this. The pattern where the same order is sent twice is covered in purchases counted twice in GTM, and the pattern where the posted count exceeds the order count is covered in GA4 purchase counts above orders. What this article covers is not the count but the moment of posting.
The mechanism by which a refund never reaches measured revenue is itself covered in GA4 revenue does not match the books. That article is about the analytics side: GA4 revenue metrics do not deduct a return unless a refund event is sent. This article is about the payment side, following how the method for deciding the posted amount changes on October 1, 2026. The two touch, and the place that changes is different.
Here the question swaps. "Close the month on net revenue after refunds" is an accounting requirement, and the payment-side data is the source of record. "Decide which channel to fund next month" is an investment judgment, and what it requires is a comparison between channels. The word revenue is shared, and the information required swaps.
What matters for allocation is which channel the refunds cluster in. If they are present across all channels in the same proportion, the relative order between channels holds before and after the refunds. If they concentrate in one channel, that channel alone appears stronger than it is.
Which channel a purchase event is attributed to is covered in revenue in the age of AI agent checkout.
RevenueScope solution
Even as the payment-side posting method changes on October 1, 2026, revenue by channel derived on the site side continues under the same definition. What RevenueScope receives as revenue is the site-side purchase event alone. Refund events are not received. What continues is where the judgment is decided. Revenue and RPS by channel are derived from the same formula in September and in October, so across the spec change the objects being compared do not swap. To review net revenue after refunds, reconcile against the payment-side data.
RevenueScope displays revenue, sessions, RPS, AOV, CVR and ROAS in the KPI summary, for the current period and against the prior period. RPS is the revenue generated per session. The channel breakdown displays revenue and RPS for each traffic source, with the prior-period comparison on the same screen. The attribution model switches between last, first, linear and time-decay for comparison.
A fictional Store N, channel RPS compared across September and October (illustrative)
| Channel | September RPS | October RPS | vs prior period |
|---|---|---|---|
| Google Search | 210 yen | 225 yen | +7% |
| Meta | 180 yen | 140 yen | -22% |
| Criteo | 95 yen | 105 yen | +11% |
Note: the demo screen shows sample data from the reference EC store and refreshes daily. The table above is separate from it, with figures composed to explain how a comparison across the spec change reads. Neither the channel mix nor the scale of the amounts matches the demo screen.
What changed on October 1, 2026 is the payment-side posting method, and both columns in this table are derived from site-side purchase events. That is why the 22% drop for Meta reads as a real change in that channel rather than an artifact of the spec change. Had the two months been compared on payment-side confirmed amounts, the comparison would sit between amounts posted under different methods, and the cause of the drop could not be isolated.
The next move is to decide whether to stop funding Meta. Before that judgment, check whether refunds are concentrated in that channel. Where refunds concentrate is information held by the store, so it is reconciled against the revenue and RPS by channel that RevenueScope displays.
FAQ#
Frequently asked questions#
Q. Does partial refund stop working on September 30, 2026?
A. The notice lists "partial capture, partial refund" in the function list with "scheduled end of support 2026/9/30." The constraints on the partial refund request carry the same date [1].
Q. How does the amount posted as revenue change from October 1?
A. The notice states that from October 1, 2026 the setting changes to specifying the amount posted as revenue, which is the same as the authorized amount [1]. The specified amount equals the authorized amount.
Q. Is a replacement procedure announced?
A. It is not stated in the notice. The same update adds a function ID called "amount change request," and no procedure for using it in place of partial capture and partial refund is stated [1]. Operations from October 1 are a matter to confirm with the payment provider you contract with.
Q. Does measured revenue fall when a refund is issued?
A. It does not. Site-side analytics post revenue at the moment of the purchase event. A refund is processed on the payment side, so no event is sent to the site side. Net revenue after refunds is confirmed from the payment-side data.
Summary#
There is one thing to check before September 30. Open the refund records for the past three months and count how many partial refunds were used. If the count is zero, the September 30, 2026 end of support does not apply to this site.
If there was a count, list those situations. How to make that amount adjustment from October 1 is not stated in the notice, so it becomes a matter to confirm with the payment provider.
On the reporting side, September and October are handled the same way. Revenue is posted at the moment of the purchase event, and revenue and RPS by channel continue under the same definition. The allocation judgment carries on with that yardstick.
See which ads actually drive revenue, at a glance
Free up to 5,000 sessions/month, AI analyst included. No credit card required. Up and running in 5 minutes.
