A typical application has a frontend (client component) and a backend (server component).
- The backend works behind the scenes. It receives user input, pulls the necessary data, and sends the data back to the frontend.
Square provides API libraries that developers embed when developing an application frontend and backend.
Developers design and construct the user experience on the web page or a mobile application using buttons, menus, links, graphics, and other elements.
A typical payment-processing application flow starts with a buyer providing payment information in the frontend UI (for example, providing card data in UI text boxes). Square provides client-side libraries to process payments. These libraries typically provide UI elements to embed in the application frontend for collecting payment information.
Square supports payment processing across multiple channels, including online, in-app, and in-person (see Payment APIs). Square provides client-side libraries for these scenarios.
Some of these client-side libraries must be used in conjunction with the server-side Square API. These include:
Online payment processing. Developers can use the Square Web Payments SDK to process payments in web applications. This SDK generates a payment token from the payment information that users provide. Developers must implement a backend that calls the Square Payments API to process payments using payment tokens as the payment source. For an example application, see Payment Processing example on GitHub.
In-app payment processing. This refers to seller-created mobile applications that buyers install on their Android or iOS devices. These applications embed the Square In-App Payments SDK in the frontend development. This SDK generates a secure payment token. The application must provide a server (backend) that calls the Payments API to take the payment. For an example application, see In-App Payments SDK: Quickstart.
Square also provides client-side libraries to process in-person payments. Because these libraries process payments end to end, your application backend does not need to explicitly call the Square Payments API to process payments. These include the:
Reader SDK. A developer embeds the Reader SDK in their mobile application frontend to process payments. In this case, the application uses the Reader SDK connected to their mobile device to process payments. Note that the Reader SDK is available only in the United States. For an example, see Reader SDK: Quickstart.
Point of Sale API. To process in-person payments using Square hardware, developers can embed the Point of Sale API in their mobile application. The API simply acts like an application switcher. When time comes to process a payment, the API switches seamlessly to the Square Point of Sale application and collects the payment with a Square Reader. Applications do not need to make any backend Square API calls. For examples, see Point of Sale API: Overview.
Bookings API. Applications can use the Bookings API to allow buyers to manage bookings with a Square seller. The application backend makes the necessary Bookings API calls to create, update, and delete bookings. For an example application, see Bookings API example on GitHub.
Subscriptions API. Applications can use the Subscriptions API to offer subscription services to buyers. These applications make calls to Square APIs (such as the Catalog API or Subscriptions API) in their backend code to set up a plan and to create and manage subscriptions. For an example application, see Subscriptions API example on GitHub.
Square backend APIs can be used with any programming language. Square supports multiple languages with SDKs and any language can call Square APIs directly.