The Square Payments API is one of 37 APIs that Square publishes on the APIs.io network, and it is the one that actually moves money. It lets applications take and manage payments by charging the payment methods supported by the Web Payments SDK or In-App Payments SDK — credit cards, gift cards, digital wallets, and ACH bank transfers. It can also record cash or external payments received outside of Square, which matters more than it sounds: it means the API is a ledger of what happened, not only a switch for what Square processed.
Operations and artifacts
Square describes this API with a machine-readable OpenAPI specification, and the published artifact set on APIs.io reflects a producer that has done the documentation work. The listed properties include:
- Documentation and an API Reference on Square’s developer site
- an OpenAPI specification
- a GraphQL definition
- an APIs.json index tying the provider’s catalog together
Tagged areas are Commerce, Financial Technology, Payments, and Point of Sale — the corners Square sits at once. The Payments API does not stand alone either. It ships beside sibling APIs for Orders, Catalog, Inventory, Customers, Invoices, Subscriptions, Gift Cards, and Loyalty, so a payment is rarely the whole transaction. It is one call in a larger commerce flow.
One sharp observation
Money operations are mutating operations, and Square’s contract shows how seriously that is taken. The OpenAPI spec carries a dedicated IDEMPOTENCY_KEY_REUSED error code and threads an idempotency_key through request bodies as a required field on the operations that create financial state. That is the correct design for anything that charges a card: a retried request after a dropped connection must not become a second charge. The idempotency key is what lets a client retry safely, and Square makes it a contract-level requirement rather than a best-practice footnote. The same spec enumerates a long list of generic error codes — currency mismatches, expired tokens, insufficient scopes — so failures are typed, not guessed. When you are debugging a declined payment at 2am, typed errors are the difference between a fix and a shrug.
Takeaway
The Square Payments API is a clean example of a financial API that treats correctness as part of the interface: idempotency keys to make retries safe, typed errors to make failures legible, and an OpenAPI contract so agents and codegen can both consume it. Start with the official Payments overview, then step back to the full catalog on the Square provider page to see how Payments connects to Orders, Catalog, and the rest of the commerce stack.