Skip to main content

Getting Started Guide

To get started, Exact’s implementation team will create an account for your organization in the Sandbox environment, along with a test sub-merchant account, and a sample underwriting workflow against which you can run your merchant applications.

Testing Environment​

Exact provides individual testing environments to partners or merchants in sandbox. Request a sandbox account.
It can be accessible in a few hours of the request. To request an application to be created for your platform, please email [email protected] and our team will work with you to get it created.

Receiving your Credentials​

You will receive an email from Exact containing your organizationId, accountId, and a workflowId.

  • The Organization ID is a unique identifier assigned only at the software partner level that will be used to identify your organization when making API calls.
  • The Account ID is the unique permanent identifier that replaces the onboarding ID for a merchant after account approval. This becomes their permanent identifier to include when making payment requests.
  • The Workflow ID is assigned to the custom merchant underwriting flow and rules designed by our Compliance and Risk teams to adjudicate the merchant accounts with predefined results that determine approvals or reviews. Applicable only at the partner level.

Once onboarded to the Sandbox, you will receive a second, invite email, similar to the one below:

getstarted-invite

Accepting the invitation will bring the user to the ExactPay Sandbox log-in screen where the user's credentials will be set:

getstarted-login

Authentication​

To get started with Exact's APIs, the user will first need to authenticate. It is important to note that Exact's API accepts two token types for authentication: User tokens and Application tokens.

User Tokens Defined

User tokens are for use with front-end applications, as they expire after 2 hours of inactivity. Exact's embedded payments APIs provide user management capabilities at an individual level and allows users to access the API via their credentials. A user's capabilities are determined by their role and permissions that facilitate access control. User tokens personalize the user experience by providing content and functions specific to each user’s roles and permissions. These tokens can be revoked when a user logs out, or changes their password. User tokens should not be used for servers or application backends unless authenticating on a user's behalf.

Application Tokens Defined

Application tokens provide long living API access. Rather than authenticating as a user, use application tokens to authenticate as an application. This is the most common form of authentication, but these tokens do require you to specify which permissions you wish to use upfront. These tokens allow the applications to access each other’s APIs, data, or functionality securely without manual user intervention.

An application token can be created with all, or a subset of, the permissions of the user who creates it. For instance, an application token could be created solely for payments, or onboarding functionality, rather than having every permission that the user has. This allows for greater application security.

Similar to the User Token, creating an Application Token provides an ID, a token, and a list of allowedPermissions, and allowedAccounts. The application token sample below has been granted the charges.create and charges.read permission. You do have the flexibility to add additional permissions or change existing permissions, but it will require you to create a new application token for the changed permissions set to take effect.

{
    "id": "645bf7e44bab8c7c1862d613",
    "label": "Allows Richards Test Application to make Payments",
    "type": "application",
    "token": "6b2a8g0a88d98c4f543112af6f9d7d88b8ebbae576b8c108622395d048e95fcedabd5b356820184",
    "allowedPermissions": [
       "charges.create",
       "charges.read"
    ]
    "allowedAccounts": [
        "62abab4bf85edc2248577ef1"
    ]
}

Application tokens can be used by your systems as long as needed, or until someone with the permission to do so deletes the token. You can also replace the existing application tokens as needed (for example the previous token is compromised, lost or permissions are changed). When making a request for a new application token, you will need to provide your application name. The application ID provided determines what application settings, such as email templates, and CORS origins (a list of allowed URLs that are valid for the application) to use for this session. Please note that currently Exact only supports a single application per partner to which the ID is assigned.

NOTE: If you plan to use ExactJS, Exact’s UI components to enter card data, you must use an application token.

It is recommended that you securely store the application token within your system as it is the primary identity and authorization key for the interactions of your application with Exactpay’s platform.

If you have questions at any time throughout the set-up process, please email [email protected].

Additional Resources​

Further information on how a Partner can navigate, and integrate the PayFac service with its platform is available at the links below: