Web Payments SDK Overview
The following video introduces the Web Payments SDK and demonstrates how to get started. For a detailed overview, see the following sections in this topic.
The SDK is the client part of the client/server Square payment solution. The SDK produces a secure one-time-use payment token that your application web client sends to your backend, where it is processed as a payment with the Payments API. The backend is the server part of the client/server Square payment solution, which processes the payment using a payment token. Square provides the Payments API as a backend solution for application developers to process payments.
Did you know?
If you intend to migrate your application from the deprecated SqPaymentForm library to the Web Payments SDK, read Migrate to the Web Payments SDK to get the specifics about replacing the SqPaymentForm integration in your application with the Web Payments SDK.
The overall implementation flow of an online payment option works as follows:
Configure the Web Payments SDK client library with your application to render a payment method form and to generate a payment token.
Configure the Payments API, or another backend service, to take the payment token and process the payment.
To view an example of an application web client, see Take a Card Payment with the Web Payments SDK. To view additional examples of supported payment methods built with the Web Payments SDK, see the Web Payments SDK showcase.
The following payment methods are available to your application to accept payment with the Web Payments SDK:
Digital wallets: Apple Pay and Google Pay
Accept digital wallet payments from Apple Pay or Google Pay
The Web Payments SDK can be integrated with your payment page in as few as 10 lines of code to provide one of the available payment methods.
The Web Payments SDK was created to make integration with your web application simpler and provide better performance. The SDK provides the following advantages:
Granular configuration. You only need to write configuration code for the payment methods that your application accepts. Each payment method has its own objects with configuration options appropriate for the method.
Promise-based pattern. The async/await pattern is used in place of the callback pattern of earlier payment libraries. This pattern lets your application react to events in a more reasonable way with less code.
Automatic localization. The SDK determines the locale of the buyer's browser automatically. However, your application can override localization by setting a configuration option.
The Web Payments SDK produces payment tokens from any of the methods listed in Payment Methods.
The payment tokens produced by these payment methods share a common format and are all accepted by the Payments API as
source_id values. The server-side Payments API code that you write for one of these tokens works seamlessly for all the other methods. You can write unique client logic for each payment method, but you only need one payment process flow on the server.
You can also get a payment token for use with the Cards API if you need to store a card on file with a customer. This is useful when your application must support recurring card-not-present payments.
The Web Payments SDK does not create a new customer in the Square account where a payment is credited. If you want to create a new customer along with a payment on a Square account, you need to collect at least one of the following pieces of information about a buyer:
Buyer email address
Buyer phone number
The backend of your application can take this information and create a customer profile
using the Customers API. When your backend creates a
Payment object using the CreatePayment endpoint, it includes the Web Payments SDK-provided payment token and the new customer ID.
The Web Payments SDK shows a postal code input field on the payment form after the SDK determines the country that issued the buyer's credit card. The Web Payments SDK displays the proper form label for the postal code based on the country:
For US, the form displays "ZIP".
For CA, the form displays "Postal Code".
For UK, the form displays "Postcode".
If the payment form displays the postal code field, then the payment requires a postal code for the buyer to proceed. The Web Payments SDK enforces input field validation for the postal code depending on the country.
The payment session times out after 24 hours. If the buyer has not completed filling out the payment form, the buyer must refresh the browser to complete the payment. Fields that generate based on the issuing country of the credit card may not save input that the buyer entered.
The Web Payments SDK cannot be used with Internet Explorer 11.
The Web Payments SDK does not create payments or customers on its own. The SDK must be used alongside the Payments API and the Customers API.
Chrome extensions do not work with the Web Payments SDK.
In the EU, payments that do not provide authentication get a
CARD_DECLINED_VERIFICATION_REQUIREDerror for transactions that require authentication. This error means that the seller did not implement
verifyBuyeron the customer-initiated payments. For more information, see VerifyBuyerError.
The following topic shows how to add card payment logic to an example application:
If you have already implemented the Payments API in your application, you can replace the
localhost domain and URL used in the Web Payments SDK example code and samples with your own server endpoint URL.
Square also provides examples of application integrations where you can initialize the Web Payments SDK with a backend to process payments. These examples are provided in GitHub.