Web Payments SDK Overview
The following video introduces the Web Payments SDK and demonstrates how to get started. For an optimal viewing experience, expand the video window to a desired size or watch the video on YouTube. For a detailed overview, see the following sections in this topic.
The Web Payments SDK enables the client implementation of the client/server Square online 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. For more information, see Take Payments.
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.
The overall implementation flow with the Web Payments SDK and a payment acceptance backend service 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 Explore 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.
If your application deploys a Content Security Policy (CSP) with the Web Payments SDK, you must enable the following CSP directives to add an additional security layer:
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 on GitHub.
Go to the GitHub repository for the Web Payments SDK quickstart application and read through the readme to get started.
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.
If you need more assistance, contact Developer Support or ask for help in the Developer Forums.