Square migration checkers can be sold as standalone tools

One transaction connection has split into three paths

Square’s application integration rules—the way other software sends payment commands and receives results—have changed. On August 15, 2019, Square said it would replace its legacy Transactions API with new payment and refund flows. About seven years later, on September 16, 2026, it ended the legacy write operations.

New payments, refunds, completion of authorised payments, and voids can no longer be handled through the old flow. The affected operations are Charge, CreateRefund, CaptureTransaction, and VoidTransaction. Specifying an earlier version does not restore them.

Reading historical transactions has not disappeared immediately. This creates a period in which new payments are handled through the Payments API, refunds through the Refunds API, and items, taxes, and orders through the Orders API, while old transactions can still be read through the legacy flow.

This is not just a rename. The maximum length of the request key used to prevent duplicate payments has fallen from 192 to 45 characters, and the field used to read totals including tips has changed. Only completed payments can be refunded; payments in an authorised state must be voided rather than refunded. A payment can be refunded up to 20 times within one year.

Before building for this change, check the market scope. Square says it supports payment processing in the United States, Canada, Japan, Australia, the United Kingdom, Ireland, France, and Spain. South Korea is not included. A Korean team would need to target sellers in those countries, such as overseas Korean stores, rather than local KRW payment use cases.

A checking tool can break away from a large management system

Consider a Korean company with eight employees that manages bookings and prepayments for 60 nail salons in the United States. Its operations lead, Minji, has handled payments and refunds through a booking number, while store staff simply press a refund button in an admin screen.

In a legacy integration centred on the Transactions API, payment methods, refunds, and order-related information were handled together. In the new structure, they are split across the Payments, Refunds, and Orders APIs. That meant the booking and customer-management provider usually owned the whole payment repair, leaving little room for a separate checking service.

Now, to verify one refund, Minji must match the booking order, the new payment ID, the payment status, the refund request, and the final refund status in sequence. For an older transaction, she must also find the legacy transaction ID. For some cash and external-payment refunds from before 2021, she must check the order record too.

That creates room for an independent migration checker. It is a small service that receives permitted request logs or code from a live product, finds the four operations that no longer work, and shows whether the new payment, refund, and order records connect through the same booking number.

On its first screen, Minji could see by store: “3 legacy refund calls,” “7 missing order links,” and “12 request keys over 45 characters.” Selecting an item would show where the problem occurs, what it should be replaced with in the new flow, and whether the result matched in a test payment.

The tool does not need to handle actual card numbers or approve payments on behalf of the customer. It can compare request logs and payment statuses within the access the customer allows. That makes it possible to start smaller than rebuilding booking, inventory, and customer management together.

Some work still needs human judgement. Stores and operations teams must decide whether to approve an order cancellation, compensate an old payment through another method, or reflect tip and fee differences in accounting. The checker should not make those decisions. It should bring missing links and failed states into one place.

Others have already turned parts of the connection into products

APIExperts, serving the US market, runs WP Easy Pay, a WordPress payment-button and form product, and WooSquare Plus, which matches online-store orders and inventory. Sellers pay for products and subscriptions, while the plugins handle Square payment, order, and customer connections.

It says it offers more than 24 Square plugins and that its two core products each have more than 4,000 connected sellers. This suggests that pieces such as payment forms, recurring payments, and order synchronisation can become standalone products rather than part of a full ecommerce system. The figures appear in a Square case study and need separate verification.

Towbook, an operations service for towing companies in the United States and Canada, began its Square integration in 2021. It lets operators collect towing and vehicle-release fees through in-person terminals, text messages, and email invoices, then records the results in towing-work records.

Square says the connected service has more than 1,000 customers and handles about 40,000 transactions a month. One customer said it eliminated manually copying card payments and saved 16 hours a week. This is also a supplier case-study figure and needs separate verification.

Stripe, which is jointly headquartered in the United States and Ireland, processes payments for online businesses and charges payment fees. It initially reduced change risk by pinning the version of its integration rules for each customer account. It now provides a screen called Workbench where users can see the version in use and request volume.

Users can return to the earlier version within 72 hours after changing to a new version. Square’s shutdown does not offer the same rollback mechanism, but it shows that a screen explaining what changed and where errors occur can itself be a distinct operations feature.

What could come out of this

1. Legacy payment-call finder

A checking service that finds the four retired operations in live code and request logs, then maps them to replacement operations. A Korean development team managing ordering software for 30 US cafés could use it.

Because the legacy calls already fail, the results can become a repair list immediately. The first screen should show the number of legacy calls by service, last-used time, replacement operation, and owner.

2. Refund status tracker

A service that shows a refund in one line from request received through in progress, completed, and failed, and flags refunds that have been stalled for a long time. It could be used by the customer-support team of a chain of 12 Korean-owned beauty salons in the United States that collects booking deposits.

Under the new refund flow, a submitted request is not automatically a completed refund, so a dedicated support screen is needed. The first screen should show refunds requested today, time in progress, failure reasons, and customers who need another contact.

3. Payment-to-order amount reconciliation

A service that compares payment amounts with order items, taxes, and tips every day, then selects only the cases with differences. A finance operator responsible for settlement across multiple locations in a Canadian restaurant-ordering app could use it.

Payment and order information now sit in separate connections, and the total field that includes tips has changed, which can increase manual reconciliation. The first screen should show payment totals, order totals, differences, and likely causes by store.

4. A customer view linking old and new transactions

A lookup service that combines legacy transaction records and new payment, refund, and order records into one chronological history for each customer. A customer-support team at a US event-registration service that has used Square since before 2021 could use it.

A customer’s record has split across two places because legacy reads remain available while new processing moved to different flows. The first screen should include customer search and a chronological status view of orders, payments, voids, and refunds.

Why this matters where you are

Any payment platform change can split records that previously appeared in one operational flow. Check whether the platforms your customers use separate payment, refund, and order data, and whether old records remain readable while new actions move elsewhere. If they do, a narrow tool that finds broken links or shows state changes may be more useful than rebuilding the full operating system.

What to check today

Ask your development provider to send a screen showing a search of the current production code for Charge, CreateRefund, CaptureTransaction, and VoidTransaction. You can receive the result within 30 minutes. If even one result appears in a live feature rather than a test file, the first customer problem for a migration checker already exists.