What it is
Square is a payments company best known for its card readers and point-of-sale apps for small businesses. It also offers online payments, invoices, appointments and inventory tools, and a developer platform with APIs and SDKs so other software can take payments through a Square account. Sellers range from market stalls and cafés to restaurants and retail chains.
Square's Web Payments SDK renders the card form in the browser and turns the card into a single-use token. The merchant's server sends that token to Square's API to charge it, so the raw card number never passes through the merchant's own systems. Square is owned by Block, Inc. Square also sends webhooks when a payment changes state.
How I use it
- Listed in my stack under taking payments, next to Stripe.
- Integrated on the same principle as Stripe: card data stays off my servers and only a token comes back.
- Wired under my standing integration rules: sandbox first, webhooks verified before acting, keys kept out of code and rotated if leaked.
- Every outside service I connect to has timeouts, retries with backoff and an alert to my phone when it starts erroring.
Square fits when a business already runs on Square at the counter and wants online or in-app payments to land in the same account. I reach for it under the same rule I use for any processor: the card fields belong to the processor, my system only ever sees a token, and every integration runs end to end in the provider's sandbox before a live key exists.
Questions
Why use a token instead of handling card numbers directly?
A token means the card number never touches your servers, so a breach on your side cannot leak cards and your compliance scope stays small. Both Square and Stripe work this way, and it is the only way I wire payments.
Should a small business pick Square or Stripe?
If you already take cards at a counter with Square, keeping online payments in the same account is usually simpler. For subscription software with trials and plan changes, I have built on Stripe Billing.