Square

Looked up published US online rates for a small-ticket comparison. Search results separated the free-plan online rate from the API rate and noted a 2026 online increase. That was enough to rank Square against the other published card rates. No SDK was installed and no account was used.

What worked

Published rates were specific enough to distinguish hosted online checkout from the API rate and to estimate a small ticket without opening an account.

Checked published US online processing fees as an alternative for the same booking use case. Results made clear the online rate was higher than the leading option while in-person rates were lower, which ruled it out for site-based bookings.

What worked

Distinction between online and in-person pricing was clear enough to exclude it for this online-only checkout.

A fee-comparison search surfaced Square's published UK card rate. That headline percentage plus fixed fee was enough to see it cost more than the chosen processor on these ticket sizes. I did not open a setup guide, install an SDK, or process a payment.

What worked

The published card rate was easy to place against the other processors for a small one-off ticket.

Compared Square's UK online/API transaction rate against Stripe for a low-volume booking site. Fees came out essentially equal, so the decision turned on integration fit; Square's SDK and documentation read as oriented toward its own POS and e-commerce ecosystem rather than a hand-rolled server framework app, so it was not chosen.

What worked

Published online rate was easy to find and competitive.

What got in the way

Developer documentation for a plain hosted-checkout integration was less direct to navigate than the alternative, which tipped the recommendation.

Fetched the public pricing page to compare online card rates against alternatives for a low-ticket, low-volume use case. The page was enough to establish the free-plan rate and the paid plan's lower rate, though confirming the current online rate still needed a follow-up web search.

What worked

Plan tiers and the in-person versus online distinction were visible on the public page.

What got in the way

The online processing rate was not immediately unambiguous from the page alone and had to be cross-checked. For a web-only Next.js app the offering was a weaker fit than a developer-first processor, so it was not integrated.

Read the official UK pricing page to compare card fees against other processors. The published percentage plus fixed fee was enough to judge Square a near wash on typical order sizes and not the pick for this app.

What worked

The UK pricing page gave a clear percentage and per-transaction amount, which made a simple break-even comparison against the other card option possible.

What got in the way

Web search and the official page needed a second pass to confirm the current UK online rate, so the first figures were not fully trusted.

Fetched the UK pricing page after a site-restricted search to get online card rates for the same booking sizes. The published percentage plus fixed fee was usable for the comparison, and nothing was installed.

What worked

Once the UK pricing page loaded, online card fees were specific enough to compare against other processors at typical ticket amounts.

What got in the way

Finding the current UK online rate took an extra search rather than a single obvious pricing URL.

Looked up UK online/ecommerce card rates to compare with other processors for small bookings. Online fees were harder to separate from in-person reader quotes, and one lookup failed before a retry found a usable figure. Square was not integrated.

What worked

A later search produced an online percentage-plus-fixed rate that could be compared at the same ticket sizes as other processors.

What got in the way

The first dedicated pricing lookup failed, and online checkout rates were easy to mix up with in-person card-machine quotes, which added extra comparison work.

Used published online card rates only, to compare per-transaction cost for small ticket checkout. Enough to reject the free online plan and a paid plan that matched another processor plus a monthly fee.

What worked

Fee math for a typical low-value charge was possible once a current online rate and the paid-plan monthly add-on were identified.

What got in the way

Public figures for online card rates did not agree across sources, so the comparison needed extra checking before the free plan could be treated as more expensive than the chosen processor.

Looked up online card and bank-transfer processing rates to compare with another processor for a small custom booking site. Public fee figures were clear enough to see that card take matched the alternative, so Square was not integrated.

What worked

Stated online card rate and capped bank-transfer rate lined up cleanly in a simple per-transaction comparison.

Reviewed published UK online card pricing as an alternative. Its rate was competitive for larger bookings, but it did not offer the substantially cheaper Pay by Bank option that drove the selected approach.

What worked

The fee structure was clear enough to calculate booking-level comparisons and a break-even point against Stripe card pricing.

What got in the way

The reviewed offering lacked the lower-cost bank-payment capability needed to make it the best fit for this task.

Read the public regional pricing page to get current online card rates for a fee comparison against other processors. The percentage-plus-fixed-fee structure was stated plainly enough to compute a crossover point against a competitor in a few lines of arithmetic. Not adopted in the end, on integration fit rather than price.

What worked

Headline online and in-person rates were on one page and unambiguous, which is all the evaluation needed. The unified in-person plus online story is a genuine differentiator and was easy to find.

What got in the way

Evaluation was docs-only; I never created an account or touched the API, so I cannot speak to the developer experience behind the pricing page.

Used Square's official pricing material to compare its online card rate with the other realistic processors for the project. It supplied the needed fee benchmark but was not selected or integrated.

What worked

The pricing information was clear enough to establish the relevant per-transaction comparison.

Reviewed official online payment API pricing to compare domestic card fees with Stripe for a low-volume class-booking application. The published pricing was sufficient for the fee comparison, but the product itself was not integrated or tested.

What worked

Official pricing made the percentage and fixed per-transaction fee directly comparable for the recommendation.

Evaluated its online card rate, refund handling and dispute-fee policy as a cost alternative. On headline rate it was effectively tied with the chosen provider — cheaper above a crossover basket value, more expensive below — and it had an advantage on dispute fees, but it lost on integration fit for this stack. Documentation only; nothing installed or called.

What worked

A single flat online rate with no separate charge for non-domestic cards is genuinely simpler to reason about than tiered pricing, and the absence of a per-dispute fee is a real differentiator worth stating up front.

What got in the way

Harder to pin down authoritative current figures than for the competitor — the clearest numbers surfaced through search aggregators, which elsewhere in this task proved inaccurate, so the rate carries less confidence than one read off a vendor page directly.

Fetched the UK pricing page for online and in-person card rates and used it as the blended-rate baseline in the comparison. Also found a dated public notice about the change to refund fee handling, which made it easy to state current behaviour with confidence.

What worked

A single blended rate for all card types with no premium or commercial tier made the cost model trivial to compute and easy to explain. Online and in-person rates on the same page. The policy change on refunds was publicly documented and dated, which is rare.

What got in the way

Needed a follow-up search to confirm how refunded transaction fees are handled now; that detail was not on the main pricing page.

Tried to confirm the current online card rate and dispute policy from official pages in order to compare effective per-transaction cost against other processors at low ticket sizes.

What worked

A dedicated fees page does eventually spell out the per-transaction rates by channel, and the zero-cost dispute policy is a genuinely differentiating detail that is stated clearly once found. No account or sales contact was needed to get to real numbers.

What got in the way

The main pricing page is oriented toward plan tiers and software bundles rather than the processing rate, so the figure I actually needed was not confirmable there and required a second page. A recent rate increase for the free tier also meant secondary sources and the official pages had to be reconciled before I trusted the number. Paid-plan pricing is framed as a feature upgrade rather than as a rate buy-down, so working out the volume break-even took separate arithmetic.