WePay supports SSO, allowing partners to enable a single sign-on for their users and eliminating the need for multiple sets of user credentials for a single user. SSO changes the way you create users and how users login. Users login to your application and you authenticate them to WePay.

With SSO, a user may have accounts with multiple partners and use the same email and password for each. Because users are siloed in this manner, they are treated as distinct entities by WePay and only have access to accounts at the partner with whom they are logged in - creating a completely partner branded experience. If the user is logged into WePay they will have access only to non-SSO applications.

user silos

Managing Users

In the non-SSO environment, account administrators can create additional users. In the SSO environment, the ability for account admins to create users is disabled in the Merchant Center.


In order to implement SSO and its associated APIs, a partner must be approved by WePay. See your account representative for more information about getting approved.

Creating Users

Use the /user/register call to create a user. Include the optional type parameter and set its value to sso.

Users created with the /user/register call containing a type parameter with a value of sso are bound to the application’s authentication system and will only be able to login through that application, and will only have access to accounts associated with the application that created the user regardless of whether the same email address already exists in the system. A user may have accounts with more than one partner using the same email address, however the user is siloed and is treated as a different user for each partner.

If /user/register is called without the type parameter set to sso the call defaults to its normal behavior and SSO is not enabled for that user.

The new SSO user must still verify their email, there are two ways to do this:

Partner Verification

Partners approved to perform their own verification can envoke the /user/mark_email_verified call.

WePay Verification

Partners not approved to perform their own verification must use the /user/send_confirmation call. SSO users receive a Thank You email and are not required to set a password. When a user clicks Next, they are sent to a partner-configured page.

Time limits

Regardless of the method used to create an SSO user, the same time limits for verification apply. see /user/register for more information about time limits.


Accounts are created in the usual manner using the /account/create call. Accounts are not different for SSO, only users.

Managing Passwords

In the SSO environment, the application is responsible for managing and securing passwords. Password management functions for SSO users are not available on the WePay site.


WePay strongly encourages SSO Partners to implement financial institution grade password management security

Login Process

The login process for an SSO requires the exchange of SSO tokens between the partner on behalf of the user and WePay. SSO tokens are not access tokens. SSO tokens are:

  • One-time use.
  • Must be signed by the application using the WePay’s Signer SDK.
  • The signed token must be returned within 10 minutes of their issuance.

SSO Token Flow

Using the Signer

The takes the following arguments as input:

  • Token: The original time-sensitive one-time token.
  • Signed Token: The token signed by the SDK.
  • Client Secret: A private key know only to the user and WePay (found on the application dashboard).
  • Client ID: A public key (found on the application dashboard).
  • Page URI: The page on WePay to which the user is directed.
  • Redirect URI: The page on the partner’s site where the user is directed from WePay. This may be used when the user clicks a button to return to the partner’s site or when the WePay session times out.

A single point entry URL can be constructed using the following components:

  • The original token.
  • The signed token.
  • The Client ID.
  • The Page URI.
  • The Redirect URI.

The URL will be similar to


This constructed URL only exist on the partner site and never linked from an email.


MFA Challenge:
If the user has MFA activated they may be challenged before proceeding to the target page.

Logging Into WePay Directly

Since the intent is to drive users directly to the partners platform, any attempt to login directly to the WePay site by an SSO user will be redirected to the partner’s platform.


WePay Initiated Contact:
There are certain use cases where WePay may send the user an email directly with a link to a page where some action is required. See the User’s Responding to Email Links Sent By WePay section, below.

Login Validity

WePay’s sessions are limited to 10 minutes from the last time a user performs any action on a page. This session may be less time than a partner’s session time-out, resulting in the user being logged out from the WePay site while still logged in on the partner’s application. In this scenario, the user is directed back to the partner’s platform.

If the user spends enough time on the WePay site, it could result in the user being logged out on the partner site before they finish their actions on the WePay site. The application can request a fresh SSO token to keep the user logged in while they complete their actions on the WePay site.

If the user closes their session on WePay before the partner time-out it can result in the user being logged into WePay and logged out at the partner site. The partner should issue a /user/logout call when their session expires.

There are a number of use cases, such as chargebacks, where WePay sends the user an email with a link to a Merchant Center page where some action needs to be taken. In this case the user is redirected to the partner site for authentication before being redirected back to the original Merchant Center page.

SSO Link Redirect Flow