Partnership isn’t just a word—it’s how we power payments.
Integrating payment services into your system is a complex task, and it grows all the more complex the more ideas and customization needs you have. We want to make that process as easy to follow as possible—from one developer to another.
We've prepared this quickstart section to help you get started. We recommend going through all of the sections in order and then moving onto the Getting Started section to find out which integration option makes the most sense for you and how to implement it in your system.
Now, if you are ready to explore...
AuthenticationA quickstart guide to authenticating with Number services
To authenticate to our services, depending on your integration of choice, you might need the following:
Here's a basic step-by-step guide on how to authenticate with our APIs:
Authenticating with the mobile SDKs is very simple. to get an API key, HMAC secret, and an optional Sentry DSN.
After installing the SDK of your choice, you can configure and initialize the EasyPay class.
To log in and use the features of Virtual Terminal, you'll first need to create accounts for your users through the Client Admin Portal.
To access the portal, . You will be asked to provide the full name, e-mail address, and cell phone number for every individual you wish to have access to the portal. Those individuals will then be able to enter the portal and create new Virtual Terminal users through the portal by entering Manage Accounts > Users through the navigation on the left.
Now, those users will be able to access the Virtual Terminal using the link below.
Use the Client Admin Portal to create a token. If you don't have access to the Client Admin Portal, contact the Number support team.
If you don't encounter a PCI Level 1 compliance warning in API reference page:
For REST API, include a SessKey header with the stored value.
In case you encounter the compliance warning in API reference page, as seen below:
You'll need to prepare a secured header and use its value in place of the original SessKey.
If the HMAC secret was not provided to you previously or you don't know how to find the value of UserID or DeviceID, .
The format for the key is as follows: SessKey_Epoch_DeviceID_Hash. Include this key in the same way as you would include the SessKey (see case above).
Learn to make credit card sales and collect consent with Number
To make sales or collect consent when a card is present using Number, you have several options:
When you have a USB card reader connected to your machine, you can log into the Virtual Terminal to make card present sales and to collect consent.
We also have a custom desktop application which can be convenient in an office setting to collect card present payments. It offers similar functionality to the Virtual Terminal.
Our REST API offers methods for handling card present transactions.
If you have your own PCI level one compliance program, you may write your own custom code calling our APIs to collect card present payments and consent. You can read more about PCI compliance in the short section of our guide.
There are a few approaches to integration, You can either use the browser-based interface option or the Desktop integration with SDK .
Before you start, you'll need to download the Verifone Windows service to your machine, connect your card reader device to a free USB port, allow it to initialize, extract the archive with the service and run the EXE as an administrator. After the installation is complete, reboot the system.
You can issue commands to the service by calling https://localhost:8031 from your website.
Here's an simplified example of how you can invoke the service for a card present sale:
Here's an simplified example of how you can invoke the service to collect annual consent:
When you want to use your Verifone with the Virtual Terminal, you have to first install the very same Windows service that is used when doing a Verifone browser-based integration. After installation, to get the card reader features activated.
When you visit the Virtual Terminal, log in and expand Credit Cards in the navigation on the left. You'll see options for a sale, an EMV sale, authorization, forced auth, and adjustments.
As long as your USB card reader is connected to your machine, it will seamlessly integrate with the Virtual Terminal for card present transactions.
When you visit the Virtual Terminal, log in and expand Consents in the navigation on the left. You'll see options for annual consent, EMV annual consent, and one-time consent. You can also expand the Recurring tab to find options to create recurring consent, EMV recurring consent, and subscription consent.
As long as your USB card reader is connected to your machine, it will seamlessly integrate with the Virtual Terminal for card present transactions.
Our APIs are useful for any Integration as you can apply a credit, void, query, charge a stored card etc. For integrators who are PCI Level one compliant you may also pass cardholder data directly through the API. Most integrations will use our PayForms to collect Cardholder data while the API will be used for all remaining activity.
When you scan the credit card and collect the track data alongside the other payment details, if using the REST API, prepare the HMAC secured header like shown in quickstart guide, and encrypt the card number using our RSA certificate.
Follow the instructions in the API reference to prepare and handle the request.
You can use the following API operations:
For the REST API, use
You can use the following API operations:
For the REST API, you can use and .
To make credit card sales and collect consent using Number when you want to enter the card details manually, you have the following options:
The PayForm is designed to be a highly flexible and secure payment form for your users. To start collecting payments and consent with the PayForm, you'll want to use our builder tool for configuration, then our REST API to generate a payment URL.
You can read about configuration specifics in the section of our full PayForm guide. For the purpose of this tutorial, you can follow the example below; we'll briefly explain each configuration step.
In the example below, the PayForm has been setup for an instant card payment.
The JSON will look like the following:
This JSON can be used to make a REST API request to generate the actual payment form.
You may re-use this JSON to generate the same type of form for multiple different users. You may also want to dynamically configure values like the amounts from your code.
To generate a PayForm, make a request to .
If you include a valid session key, the PayForm will be accessible under the PaymentUrl included in the response. You can embed it into your site or redirect the user to the page.
Once the user fills out and submits the form, we'll handle the payment.
If you want to handle the query string when redirecting back to your website to store the transaction ID in your database, read the section of our full PayForm guide.
To use the PayForm to save a card on file, follow the steps in , change the transaction type to collecting cardholder data, and skip the amount field.
You may also collect an instant payment and consent at the same time by choosing the combo widget as your transaction type.
The Virtual Terminal is a web application that allows you to manually enter credit card details and process transactions through your browser.
When you visit the Virtual Terminal, log in and expand Credit Cards in the navigation on the left. You'll see options for a sale, an EMV sale, authorization, forced auth, and adjustments. Follow the instructions and manually enter the cardholder details to make a sale.
Using the Virtual Terminal, you can create annual, one-time, recurring, and subscription consents. Log in and expand Consents and Recurring tabs on the left side of the screen. Choose the type of consent you're interested in and follow the instructions to manually enter the cardholder details and store a card on file.
If you are developing an Android or iOS application, you can utilize our SDKs to charge credit cards and collect consent manually by having users enter their own details.
The relevant methods are described in section of the guide and section of the guide.
The relevant methods are described in section of the guide and section of the guide.
If you wish to have more control over the integration and you are PCI Level 1 compliant, you can try using our APIs. They provide methods for all payment types available using our other services, including manual card sales and collecting different types of consent.
After authenticating, when you collect cardholder data alongside the other payment details, if using the REST API, prepare the HMAC secured header like shown in quickstart guide, and encrypt the card number using our RSA certificate. Follow the instructions in the API reference to prepare and handle the request.
You can use the following API operations:
For the REST API, use .
You can use the following API operations:
For the REST API, use for annual consent and for recurring consent.
The Virtual Terminal website allows you to handle manual card sales and consent collection by default. This approach requires no coding and is perfect for a physical point-of-sale.
We also have a custom desktop application which can be convenient way to collect manual card payments and consent. It offers much of the same functionality as the Virtual Terminal.
For more customization, you can call our API for sales and consent.
If you have your own PCI level one compliance program, you may write your own custom code calling our API to collect manual card payments and consent. You can read more about PCI compliance in the short section of our integration guide.
The PayForm will redirect the user to an external URL. An encrypted query string containing the POST data will also be appended to the URL
{
"InitParams": {
"MerchID": 1,
"WTYPE": "PF",
"PostURL": "",
"RedirectURL": "https://yourwebsite.com/success",
"REF_ID": "",
"RPGUID": "",
"EndPoint": "PayForm/PF.aspx",
"EINDEX": "300",
"Amounts": {
"Amount": 25,
"Surcharge": 0,
"TotalAmt": 25
},
"Payer": {
"Firstname": "",
"Lastname": "",
"BillingAddress": {
"StreetAddress": "",
"City": "",
"State": "",
"ZIP": "",
"Country": ""
},
"Email": "",
"Phone": ""
},
"WidOptions": {
"eVisible": "6E7F",
"eReadOnly": "0040",
"eStyles": "0001",
"eSubmission": "0201",
"eColors": "#ffffff,#6cca44,#59ff00,#212121,#ffffff,#212121,#ffffff"
}
}
}
Find the information you need through the API or Virtual Terminal
If you need to find a specific record in our database (such as a transaction or saved consent) or you need to find all records matching your criteria, you can either query our APIs programatically or use the Virtual Terminal to view and filter the records from its user interface.
To query records, you'll need to find a relevant method in the REST API reference.
When querying, you'll need to prepare the Query string. It should consist of variables that correspond to fields on the records and logical terms built using those variables.
All Query string variable options are fully described in the API reference under specific API methods and in the reference. You can use the variables to build logical terms, and you can build and join logical terms using "&&" for a logical AND or "||" for a logical OR.
Read about Number's query language in our reference.
As an example, if want to find settled ACH transactions made in January 2025 made using Verifone card readers, you can call or depending on which API you are using.
You can check the description of the Query string parameter or check the reference for section to find out that variable 'B' corresponds to transaction status, variable 'C' corresponds to date created, and 'U' corresponds to the transaction origin.
Each variable which requires an enum includes a description of valid values. Settled transactions have a transaction status of '2', and Verifone transactions have an origin of 'SDK'. To format the date correctly, follow the examples given for the variable.
You can combine the filters to build your Query string like so:
You can filter consents, transactions, and other records through the Virtual Terminal user interface.
To log into the Virtual Terminal, you need to have a user account created through the Client Admin Portal as described in the quickstart guide.
Once you're logged in, see the navigation on the left and click on Scheduled to view scheduled payments, click on Settlement to view settlements, or expand Reports to find other reports. There, you'll be able to search and filter records using the user interface.
You can read more about using the Virtual Terminal in the guide.
(B=2)&&(C>='1/1/2025')&&(C<='1/31/2025')&&(U='SDK')
Send payment reminders to clients through text or e-mail
As an integrator, you may wish to send a payment reminder to a client through a text or e-mail which will allow them to pay the amount due. Here's an example reminder:
You have a payment due to Merchant XYZ of $125.00 due on 10/4/2016. Please follow the link below to make the payment. https://easypay5.com/stdwidget/?SP=E8E5EC
Once they receive the reminder, they can click the link that is sent along with the message to open a payment page. This will allow them to enter their card details and make a payment.
After the payment is submitted, a transaction receipt would be sent to the e-mail address on file.
To send a payment reminder using the REST API, use the endpoint.
Both implementations use a similar body structure, and the fields are described below.
If you didn't catch any exceptions and your response is not null, check the value of FunctionOK. If FunctionOk is false, it indicates an error that was handled on the Number servers. You can find more details by looking at ErrMsg and ErrCode included in the response.
You don't have to do anything else, the reminder was sent successfully. A friendly response message is included in RespMsg field, and the PaymentURL is also returned if you wish to store it.
Amount
The $ amount to collect.
ConsentID
Not used, please fill with 0.
DueOn
The payment due date in mm/dd/yyyy or yyyy/mm/dd format to display to the customer.
EINDEX
This is your unique Integrator Key Index for encryption. It should be provided by Number when you make an account with us, otherwise .
MerchID
The unique identifier for the Merchant record.
TXID
Not used, please fill with 0.
WType
This specifies which payment widget to display, including custom widgets built for your company.
RedirectURL
This specifies where to redirect the user and post the results of the transaction.
WidgetURL
The endpoint for the widget payment form, including custom forms. and we will provide you with a value. You can start with
ExpiresOn
A date in yyyy-mm-dd format for when the payment link should no longer be available.
SingleUse
Indicates whether the payment link should only accept a single payment.
OptParams
Parameters which control the design and behavior of the payment form including the visible fields, read-only fields, color and styling, and submission options. See the section in the guide to learn how you can generate those parameters.
Person
The name, address, email, and phone number for the payee.
MessageType
The type of message for the payee.
EMAIL: Send an email with a link to the payment form
URLONLY: Only return a URL to the payment form in the response
TEXT: Send a text message with a link to the payment form
RefID
A custom user-defined field to save with the transaction.
RPGUID
Another custom user-defined field to save with the transaction.
MessageBody
The message to send. Use **Merch1** to insert merchant's name into your message template. If the body is left empty, a default generic message will be used:
You have a Payment Due to [Merchant Name] of [Amount] due on [DueOn]. Please follow the link below to make the Payment. [Link Here]
AcctHolderID
Not used, please fill with 0.
