rectanglehealth

API Overview

User Guide

Gateway References

Test Information

Terminal Devices

Workflows

## Introduction

---

The TransactionAPI is a RESTful API for interfacing with the Gateway. The API includes familiar transaction types from the BridgeComm API in a user friendly JSON interface.

## Key Elements

---

The Transaction API request and response structure is made up of a core set of data elements plus specific objects and their sub-elements. Each object handles a subsection of API data elements like payment data, Healthcare, or Level II/III information elements. The core data elements are within the main request body and will include basic information like accountType, holderType, and transactionType.

A list of all required and optional data elements can be found in each section.

In the live environment, transactions must be initiated over an SSL-protected connection using a minimum of 128-bit encryption to protect sensitive data. Initial testing can be performed over an unencrypted connection; however, testing must be performed over an SSL-encrypted channel before a client can be certified to production. Only test card/ACH account data may be transmitted. No live payment information should ever be transmitted to the test system.

## Timeouts

---

The Transaction API has an internal timeout of 100 seconds. Integrating applications can expect all transactions to take less than 100 seconds, and if 100 seconds are exceeded without a response from the Transaction API, you may close your connection. If a transaction as attempted leveraging an invoiceNumber, you may use a Find Transaction request using your unique invoiceNumber to confirm the outcome of the transaction.

## Authentication Information

---

Each call to the Transaction API requires credentials; however, these credentials are not submitted in the request body. The **username** and **password** are values created in MyBridgePay, and they will be submitted in the request headers as Basic HTTP authentication.

The Credentials object is used as a property of other objects in the API. The Credentials Object contains two properties: **username** and **password.**

Transaction API

The following section contains examples of Card Not Present transactions through the Transaction API. A card not present transaction is defined as a transaction in which the card data was not directly read off of the card and instead manually keyed into a program, web page, or virtual terminal. The card information is then formatted into a Transaction API request and used to process a transaction.

It is recommended that card data collected on a web page be collected using BridgePay's TokenPay.js product. See the TokenPay.js folder for more information.

Card Not Present

The following section outlines the various non-transaction functions provided by the gateway.

Functions

Card Not Present - TokenPay.js

The following examples show how to process a credit card/ACH sale using TokenPay.js data.

See the Authentication section above for a description of how the Authorization Header is built. In Javascript, using PostMan environment variables, the pre-request script will look like this:

``` javascript
var authorizationTokenPay = pm.environment.get("AuthenticationTokenId") + ":" + pm.environment.get("TokenPayPrivateKey")
pm.environment.set("AuthorizationTokenPay", "TokenPay " + btoa(authorizationTokenPay));

 ```

TokenPay Sale

TokenPay Sale w/ Custom Fields

The following request shows how to process a Card/ACH Verification transaction using TokenPay.js data. This request is used to validate card information without processing an authorization.

  
See the Authentication section above for a description of how the Authorization Header is built. In Javascript, using PostMan environment variables, the pre-request script will look like this:

``` javascript
var authorizationTokenPay = pm.environment.get("AuthenticationTokenId") + ":" + pm.environment.get("TokenPayPrivateKey")
pm.environment.set("AuthorizationTokenPay", "TokenPay " + btoa(authorizationTokenPay));

 ```

TokenPay Card Verification

The following request shows how to create a multi-use token using TokenPay.js dataI. This request is used to tokenize card/ACH information without processing an authorization.

  
See the Authentication section above for a description of how the Authorization Header is built. In Javascript, using PostMan environment variables, the pre-request script will look like this:

``` javascript
var authorizationTokenPay = pm.environment.get("AuthenticationTokenId") + ":" + pm.environment.get("TokenPayPrivateKey")
pm.environment.set("AuthorizationTokenPay", "TokenPay " + btoa(authorizationTokenPay));

 ```

TokenPay PaymentMethodToken

## Overview

---

PayGuardian Cloud is a web-based hosted service used to interact with EMV devices for securely processing transactions with your Point of Sale. The RESTful API allows for easy interactions via simple JSON requests.

Highlights include:

- Hosted web services gives you the ability to POST a transaction request to any terminal at any location
    
- Automated network discovery establishes and maintains a persistent connection to the gateway
    
- Multiple registers and credit card terminals can be used simultaneously
    
- Automates updates-no software installation necessary
    
- PA-DSS compliant & TLS 1.2
    
- No access to sensitive card data
    

## Connection Strings

---

**< TEST URL >**

[https://pgc.bridgepaynetsecuretest.com/req/payment](https://documenter.getpostman.com/view/24254550/2s9XxsWbyv)

The **mode** key should always be set to UAT when POSTing to this URL.

**< PRODUCTION URL >**

[https://pgc.bridgepaynetsecuretx.com/req/payment](https://documenter.getpostman.com/view/24254550/2s9XxsWbyv)

The **mode** key should always be set to PROD when POSTing to this URL

## Key Elements

---

### Prerequisites

Before continuing, you should have test merchant account credentials and a Cloud certified device.

### Devices

Terminals intended for use in production must be injected with the Production Rectangle Health P2PE key.  
Terminals intended for use in UAT must be injected with the Test Rectangle Health P2PE key. Please reach out to Payments ([payments@rectanglehealth.com](https://mailto:payments@rectanglehealth.com)) for key  
information.

##### < PAX >

PAX A Series devices are WiFi enabled and complete the same integration process for PG Cloud. The A Series requires a download of the PayGuardian Cloud Mobile App from the PAXStore to load onto the device. For PAXStore access or app related issues, please email \[[paxstore.support@pax.us](https://mailto:paxstore.support@pax.us)\](mailto: [paxstore.support@pax.us](https://mailto:paxstore.support@pax.us)). PAX requires anyone using their device to be registered with the PAXStore.

The following PAX A Series devices are currently supported:

- A920 Max
    
- A80
    
- A800
    

##### < Ingenico >

Ingenico Tetra Lane devices are ethernet based processing terminals and require basic configuration to install PayGuardian Cloud.  
The following Ingenico Tetra Series devices are currently supported.

- Lane 3000
    
- Lane 7000
    

## Process Flow

---

PayGuardian Cloud acts as middleware to save the integrator from interfacing directly with the device itself. The process flow is a simple request and response; however, the request  
will trigger the device to prompt for the card and process the transaction.  
Once the transaction is processed, the response data is fed back up the chain to the gateway and the integrated POS system.

## Authentication Information

---

Each request to PayGuardian cloud requires credentials to authorize. These values are defined in full in the Request and Response information section, and they are listed below:

- username
    
- password
    
- merchantAccountCode
    
- merchantCode
    

## Request & Response Information

---

The following tables outline the available data elements in the PayGuaridan Cloud API.

#### Request

| **Condition** | **Data Element** | **Data Type** | **Description** |
| --- | --- | --- | --- |
| Required | locationID | string | The GUID generated by PayGuardian Cloud in the PAX PayGuardian Application or provided by BridgePay in the Ingenico setup process. |
| Optional | terminalID | string | terminalID value can match the locationID. |
| Conditional | merchantAccountCode | string | The merchant account code for the gateway on which the transaction should be procesed. The PAX device may not require it as it is configured within the deivce. |
| Conditional | merchantCode | string | The merchant code for the group to which the processing gateway belongs. The PAX device may not require it as it is configured within the deivce. |
| Required | mode | string | The environment in which you are processing. The valid values are: PROD, UAT |
| Conditional | username | string | The username to be used to process the transaction. The PAX device may not require it as it is configured within the deivce. |
| Conditional | password | string | The password for the user account processing the transaction. The PAX device may not require it as it is configured within the deivce. |
| Required | tenderType | string | The type of card used in the transaction. The valid values are: CREDIT, FUNCTION |
| Required | transType | string | The transaction type for the request. The valid values are: ACCOUNT_VERIFICATION, CAPTURE-ALL, CAPTURE, FIND_TRANSACTION,PING, SALE-AUTH, SALE |
| Conditional | invNum | string | The invoice number associated with the transaction. Note that this is required for the following transaction type: FIND_TRANSACTION (by invNum). |
| Conditional | pnRefNum | string | The gateway transaction ID to be used for a follow-on transaction. Note that this is required for the following transaction types: CAPTURE, FIND_TRANSACTION. |
| Conditional | holderType | string | Single character, either P (Personal account) or O (Organization account).  <br>Note that this is only required for Account Verification. |
| Conditional | transIndustryType | string | Must either match a 2-letter industry type for credit cards.  <br>Credit Card Supported values are: RE (Retail), EC (eCommerce), HC (HealthCare). Note that this is only required for Account Verification. |
| Conditional | accountType | string | Single character, must match pre-defined types: R (Credit Card & Branded Debit Cards). Note that this is only required for Account Verification. |
| Required | amount | double | The dollar amount for the transaction. Written with an explicit decimal, so five dollars is written as "5.00". |
| Conditional | state | string | The state associated with the card. Note that this is only required for Account Verification in Test environment. |
| Conditional | zip | integer | The ZIP code for the cardholder. Note that this is only required for Account Verification in Test environment. |

#### Response

Please note that responses may vary depending on the API request and the terminal device used (Ingenico or PAX).

| **Data Element** | **Description** |
| --- | --- |
| approvedAmount | The amount approved by the processor for the transaction. |
| authCode | The authorization code of the transaction. |
| avsMessage | The AVS response message for the transaction. |
| cardHolderName | The name on the card used for the transaction. |
| cardType | The type of card used in the transaction. Example: VISA |
| cashBackAmt | The cash back amount processed in the transaction. |
| entryMode | The mode of entry for the transaction. Example: Contactless |
| expirationDate | The expiration date of the card used in the transaction. |
| extData | The extData is additional JSON values that are not part of the core values in the API. This is used for industry specific values like Healthcare, Car Rental, and Lodging.  <br>For a complete breakdown of these addition fields, please see the secondary table below this one. |
| gatewayMessage | The gateway result message for the transaction. |
| gatewayResult | The gateway result code for the transaction. |
| hostCode | The gatewayTransactionID for the transaction. |
| hostResponse | The host response code. |
| invNum | The invoice number provided in the transaction request. |
| locationID | The locationID provided in the transaction request and used to process the transaction. |
| maskedAccountNumber | The masked card number for the card used in the transaction. |
| message | The gateway result message for the transaction. |
| pnRefNum | The gatewayTransactionID for the transaction. |
| rawResponse | The Base64 encoded XML response containing more specific card information. |
| refNum | The gatewayTransactionID for the transaction. |
| remainingAmount | In the case of a partial authorization, this indicates the amount remaining to be captured after the partially authorized amount. |
| requestID | The dynamically created request ID generated by PayGuardian Cloud for each transaction. |
| requestedAmount | The total requested amount for the transaction. |
| resultCode | The gateway result code for the transaction. |
| resultTxt | The simple response text for the result of the transaction. |
| submittedAmount | The total amount submitted for the transaction. |
| terminalID | The terminalID used to process the transaction. |
| timestamp | The date-time stamp of when the transaction occurred. |
| tipAmount | The tip amount processed for the transaction. |
| token | The generated token for the card used in the transaction. This value can be stored for use in transactions through the Transaction API. |
| transactionCode | The gatewayTransactionID for the transaction (Not applied to Ingenico). |

Card Present - PayGuardian Cloud

The CREDIT tender type is used to identify any credit card transaction. To refund or void a transaction, please use the Transaction API.

CREDIT

Functions are a special tender type that can be used to execute administrative functions at a location remotely. These include updating settings, scanning for new terminals, updating properties, etc. Caution should be used because it is possible to permanently disable a network appliance if settings are updated to invalid values. These should only be executed by a  representative or a network administrator.

EndFragmenrepresentative or a network administrator.

Functions can be used by setting the `tenderType` to FUNCTION and the `transType` to the function name.

FUNCTION

## Introduction

---

The Wallet API provides the ability to create and manage wallet views usable.

## Construct

---

Components that make up the structure on the Wallet API and its usage.

- **WalletSite** - a collection of wallets. It is agnostic in that it has no requirement to be associated with any given merchant account, merchant group, or reseller. It can also be shared among multiple merchant accounts, belonging to multiple merchant groups, and even resellers.
    
- **Wallet** - a wallet belongs to a wallet site and represents a single payment method (Credit Card/ACH).
    
- **Payment Method** - contains all the necessary information to perform a transaction (Token, Expiration Date/Routing Number) and AVS information.
    
- **Merchant Account Subscribes to a Wallet Site** - multiple merchant accounts can subscribe to the same wallet site (effectively sharing payment information data), but one merchant account cannot subscribe to multiple wallet sites.
    
- **Contract in Recurring Billing** - exists between a merchant account and a customer of the merchant account.
    
- **Customer Account** - describes the customer (one of the parties in the contract)
    
- **Financially Responsible Party** - a person or business that has access to one or more wallets. A customer account can have multiple financially responsible parties
    

## Order of Process Flow

---

The order in which each Wallet API component must be created or used is below.

**1\. Create a WalletView**

- Use CreateWalletView endpoint to create a new Wallet.
    

**2\. Get all the Wallet Details**

- Use WalletView Model endpoints to get the details for the created wallet.
    

**3\. Call Transaction API with the Wallet Details**

- Call Transaction API using the relevant data elements instead of using Token, Card Number, Expiration Date, Bank Account Number, Routing Number, etc. For Transaction API, use walletPaymentMethodId and customerWalletId.
    

## Authentication

---

Each call to the Wallet API requires credentials. The Credentials object is used as a property of other objects in the API. The Credentials Object contains two properties: **UserName** and **Password**.

Both properties are strings.

## Testing and Integration Support

---

In the live environment, transactions must be initiated over an SSL-protected connection using a minimum of 128-bit encryption to protect sensitive data. Initial testing can be performed over an unencrypted connection; however, testing must be performed over an SSL-encrypted channel before a client can be certified to production. Only test card/ACH account data may be transmitted -_no live payment information should ever be transmitted to the test system._

You may use the following test payment account information in testing:

| **Payment Type** | **Token** | **Routing Number** | **Expiry Date** | **Security Code** |
| --- | --- | --- | --- | --- |
| MasterCard | 5439750001500347 |  |  |  |
| Visa | 4005550000000019 |  |  |  |
| Discover | 60011111111111117 |  |  |  |
| Diners | 36999999999999 |  |  |  |
| AMEX | 374255312721002 |  |  |  |
| ACH | 11110000000000279992 | 021000021 |  |  |

WalletAPI

The WalletAPI provides objects called WalletViews which represent a single Wallet + Payment Method combination. Wallets provisioned in MyBridgePay can have multiple payment methods. WalletViews provisioned by the Wallet API are one Wallet & Payment Method combined.

## Request Information

---

The following table outlines the available data elements for WalletView Model endpoints.

| **Condition** | **Data Element** | **Date Type** | **Length** | **Description** |
| --- | --- | --- | --- | --- |
| Required | Credentials | object |  | Each call to the Wallet API requires credentials. The Credentials object contains two properties: **UserName** and **Password**. Both properties are strings. |
| Conditional | SiteId | GUID |  | The SiteID for the Wallet Site that contains the WalletView. This is **required for GetWalletViewByCustomerId endpoint**. |
| Conditional | WalletId | GUID |  | The unique ID generated by the API for the Wallet portion of the Wallet View. This is **required for GetWalletViewByWalletId endpoint**. |
| Conditional | PaymentMethodId | GUID |  | The unique ID generated by the API for the Payment Method portion of the Wallet View. This is **required for GetWalletViewByPaymentMethodId endpoint**. |
| Conditional | CustomerWalletId | string |  | The client provided custom ID for the Wallet. This is **required for GetWalletViewByCustomerId endpoint**. |

WalletView Model

This section describes how to create and manage Wallet Views associated with a Wallet Site. The Wallet View combines the wallet, payment method, and financially responsible party into one simplified structure.

## Request Information

---

The following table outlines the available data elements for WalletView Management endpoints.

| **Condition** | **Data Element** | **Date Type** | **Length** | **Description** |
| --- | --- | --- | --- | --- |
| Required | Credentials | object |  | Each call to the Wallet API requires credentials. The Credentials object contains two properties: **UserName** and **Password**. Both properties are strings. |
| Required | SiteId | GUID |  | The unique ID of the Wallet Site to associate the WalletView with. This is **required for GetWalletViewByCustomerId endpoint**. |
| Conditional | WalletId | GUID |  | The unique ID generated by the API for the Wallet portion of the WalletView. This is **required for UpdateWalletView endpoint** and also **when activating or deactivating WalletView via Wallet Id**. |
| Required | Name | string |  | The name of the Wallet. This is **required except for activating and deactivating WalletView**. |
| Conditional | CustomerWalletId | string |  | The client provided custom ID for the Wallet. This is **required when you activate or deactivate WalletView via CustomerWalletId**. |
| Optional | CustomerAccountNumber | string |  | Client provided value representing their customer’s account number associated with the Wallet. Allows for alpha-numeric characters, periods ".", and hyphen "-" characters. Do not include other special characters. |
| Optional | isActive | boolean |  | The active status of the Wallet. |
| Conditional | PaymentMethodId | GUID |  | The unique ID generated by the API for the Payment Method portion of the WalletView. This is **required for UpdateWalletView endpoint** and also **when activating or deactivating WalletView via PaymentMethodId**. |
| Conditional | PaymentMethodType | byte |  | Identifies the type of payment method associated with the Wallet View. This is **required for CreateWalletView endpoint**. The valid value should be assigned according to the payment type (**0 = Credit Card, 1 = ACH**). |
| Optional | AccountType | string |  | Used to further identify an ACH account (“Checking” or “Savings”). |
| Optional | LastFour | string |  | The last four numbers of the account number. |
| Optional | AccountHolderName | string |  | The name of the account holder on the payment method. (Used for AVS). |
| Optional | AccountHolderZip | string |  | The postal code on the address of the payment method. (Used for AVS) |
| Optional | AccountHolderPhone | string |  | The phone number on the payment method account. |
| Optional | AccountHolderEmail | string |  | The email address associated with the account holder. |
| Conditional | ExpirationDate | string |  | The expiration date for the payment method (**required when recording a Credit Card payment method**). |
| Conditional | RoutingNo | string |  | The routing number for the payment method (**required when recording an ACH payment method**). |
| Required | Token | string |  | The tokenized account number. This is **required except for activating and deactivating WalletView**. |
| Optional | MaxFailures | integer |  | The number of failures allowed before the WalletView is deactivated. The valid value range is 0 to 10. If it is not provided when creating a new WalletView, the default value 0 will be assigned. |
| Optional | CardType | string |  | The card type that represents the payment card type. |
| Optional | WalletCustomFields | list |  | A list of the custom fields. The Wallet can be created with custom field. The format is as follows:  <br>"WalletCustomFields": \[  <br>{  <br>"Id": "",  <br>"Value": "value"  <br>}  <br>\] |

WalletView Management

## Introduction

---

The Transaction Reporting API allows users to retrieve transaction data through a SOAP request made to the service. Users can include parameters in the SOAP method to filter the data and receive a response containing the requested information.

## Key Elements

---

Skip and Take fields are required when calling the API. Transaction Rows and Batch Details will be limited to 1000 at a time. Using take and Skip you can obtain larger data sets in multiple calls. For instance, if 1,500 records are available based on the filter information sent in, the first 1000 records would be obtained by sending in 1000 for Take and 0 for skip. The next 500 records would be obtained by sending in Take for 500 and skip for 1000.

## Authentication Information

---

Credentials are required to access the Transaction Reporting API.

See below for the Data Access Rule:

- Merchant Account Users only have access to data within their merchant account.
    
- Merchant Group Users have access to data within their merchant group where access has been granted, reporting API results will exclude data associated to merchant accounts where access has not been granted.
    
- Sales Agent Users have access to data within their sales agent hierarchy where access has been granted, reporting API results will exclude data associated to merchant accounts where access has not been granted.
    
- Reseller Users have access to data within their reseller hierarchy where access has been granted, reporting API results will exclude data associated to merchant accounts where access has not been granted.
    

## Request Information

---

The following table outlines the available data elements for filtering the transaction data.

| **Condition** | **Data Element** | **Date Type** | **Validations** | **Description** |
| --- | --- | --- | --- | --- |
| Optional | AccountHolderName | string | Exact Match | When provided limits the results to those transactions that have an account / card holder name matching the submitted value exactly. |
| Optional | AccountTypeIndicator | string | Exact Match | When provided limits the results to those transactions with the matching Account Type Indicator.  <br>  <br>Valid Values:  <br>A = Amex  <br>B = Bank Card  <br>C = CUP  <br>D = Discover  <br>E = EBT  <br>G = Gift  <br>M = Mastercard  <br>N = Diners  <br>V = Visa |
| Optional | AccountTypeTransform | string | Exact Match | When provided limits the results to those transactions with the matching AccountTypeTransform.  <br>  <br>Valid Values:  <br>AMEX  <br>FSA VISA  <br>FSA MASTERCARD  <br>VISA  <br>MASTER CARD  <br>DINERS CLUB  <br>BANK CARD DEBIT  <br>PAPER CHECK  <br>CHECKING  <br>SAVINGS  <br>DISCOVER  <br>CASH BENEFIT  <br>FOOD STAMPS  <br>GIFT CARD  <br>CASH  <br>CHINA UNIONPAY |
| Optional | AmountRangeFrom | Integer (Implied Decimal) | Greater Than or Equal To | When provided, limits the results to those transactions that meet or exceed the amount provided. Integer 100 is $1.00 |
| Optional | AmountRangeTo | Integer (Implied Decimal) | Less Than or Equal To | When provided, limits the results to those transactions that are less than or equal to the amount provided. Integer 100 is $1.00 |
| Optional | AuthorizationCode | string | Exact Match | When provided limits the results to those transactions that have an authorization code returned from the processor matching the submitted value exactly. |
| Optional | BatchID | integer | Exact Match | When provided limits the results to those transactions that are part of the requested batch. |
| Optional | CardBrand | string | Exact Match | When provided limits the results to those transactions that match the submitted value exactly.  <br>  <br>Valid Values:  <br>AMEX, DISCOVER, MASTERCARD, DINERS and VISA |
| Optional | CardholderFirstName | string | Exact Match | When provided, limits the results to those transactions where the first name matches the data provided. |
| Optional | CardholderLastName | string | Partial Match | When provided, limits the results to those transactions where the last name contains the data provided. |
| Optional | ClerkId | string | Exact Match | When provided, limits the results to those transactions where the clerk id matches the data provided. |
| Optional | ContractID | integer | Exact Match | When provided, limits the results to those transactions where the ContractID used in recurring billing matches the data provided. |
| Optional | CustomFields | list | Exact Match (Key and Value) | When provided limits the results to those transactions where the Key Value pair match exactly the data provided. Attempting to filter by custom fields is only applicable if custom fields were previously defined via the Boarding API. |
| Optional | DateRangeFrom | DateTime (YYYY-MM-DDTHH:MM:SS) | On or After | When provided, limits the results to those transactions whose sale dates are on or after the date and timestamp provided. |
| Optional | DateRangeTo | DateTime (YYYY-MM-DDTHH:MM:SS) | On or Before | When provided, limits the results to those transactions whose sale dates are on or before the date and timestamp provided. |
| Optional | EndPartialAccountNumber | string | Exact Match | When provided, limits the results where the last four of the account/card number match the data provided. |
| Optional | EntryModeTransform | string | Exact Match | When provided limits the results to EntryModes as defined.  <br>  <br>Valid Values:  <br>SWIPE, CHIP READ, KEYED |
| Optional | FeeIsSurcharge | boolean | Exact Match | When provided, limits the results to those where FeeIsSurcharge matches the boolean value provided. |
| Optional | ID | integer | Exact Match | When provided, limits the results to transaction where the gateway transaction ID matches the data provided. |
| Optional | InvoiceNumber | string | Exact Match | When provided, limits the results to those transactions whose InvoiceNumber matches the data provided. |
| Optional | MerchantAccountID | integer | Exact Match | When provided, limits the results to those transactions processed for the provided Merchant Account ID. This is the Merchant Account Code. This value cannot be used with MerchantId. |
| Optional | MerchantID | integer | Exact Match | When provided, limits the results to those transactions processed for the provided Merchant ID. This is the Merchant Code. This value cannot be used with MerchantAccountId. |
| Optional | OrderByList | list | Exact Match (Key and Value) | When provided, the results will be sorted by the value in either ‘Ascending’ or ‘Descending’ order. Note: This property replaces SortBy.  <br>Example:  <br>Key: BatchID  <br>Value: Descending  <br>BatchIDDescending |
| Optional | OrganizationId | integer | Exact Match | When provided, limits the results to those transactions whose Organization ID matches the data provided. |
| Optional | PaymentMethodID | string | Exact Match | When provided, limits the results to those transactions whose Payment Method ID matches the data provided. Two letter code that identifies the payment method transaction type.  <br>  <br>Valid Values: AC (Amex),BC (Bank Checking), BD (Bank Card Debit), BS (Bank Savings), DC(Discover Credit), DD (Discover Debit), EC(EBT Cash Benefit), EF (FoodStamps), FL (Fleet One), GF (Fuelman Fleet Wide), GG (General Gift), MC (MasterCard Credit), MD (MasterCard Debit), MF (MasterCard Fleet), MP (MasterCard Prepaid), NC (Diner’sClub), VC (Visa Credit), VD (Visa Debit), VF (Voyager),VP (Visa Prepaid), VS (VisaFleet), WX (WrightExpress) |
| Optional | PaymentMethodIndicator | string | Exact Match (Second Character of PayMethodID above) | When provided, limits the results to those transactions whose Payment Method Indicator matches the data provided. |
| Optional | PaymentMethodTransform | string | Exact Match | When provided, limits the results to those payment methods.  <br>  <br>Valid Values:  <br>ACH, CASH, CHECK, CREDIT, DEBIT, EBT, GIFT |
| Optional | PurchaseOrderNumber | string | Exact Match | When provided, limits the results to those transactions whose Purchase Order Number matches the data provided. |
| Optional | ResellerID | integer | Exact Match | When provided, limits the results to those transactions processed for the provided Reseller ID. |
| Optional | ResponseCode | string | Partial Match | When provided, limits the results to those transactions where the response code contains the data provided. Please refer to Response Code Table. |
| Optional | SettlementStatus | string | Exact Match | When provided, limits the results to those transactions that match the status provided. Settled or Unsettled are acceptable values. |
| Required | Skip | integer |  | Determines how many records should be skipped before returning results. Required for paging. |
| Required | Take | integer |  | Determines how many records will be returned in the results. |
| Optional | TransactionSourceIP | string | Exact Match | When provided, limits the results to those transactions that were sent from the IP address provided in the filter.  <br>Example: 192.168.15.155:65010 |
| Optional | TransactionStatus | string | Exact Match | When provided, limits the results to those transactions whose current status matches the filter provided.  <br>  <br>Valid Values:  <br>Open, Confirmed and Voided |
| Optional | TransactionType | string | Exact Match | When provided, limits the results to those transactions whose current Type matches the filter provided.  <br>  <br>Valid Values:  <br>Auth, Sale, Refund, Activate, Deactivate, Reactivate, Inquiry, Unknown, Error, Decline |
| Optional | TransactionTypeTransform | string | Exact Match | When provided, limits the results to those transactions whose current Type matches the filter provided.  <br>  <br>Valie Values:  <br>Auth Only, Sale, Refund, Activate, Deactivate, Reactivate, Inquiry, Unknown, Error, Decline, Void, Verification |
| Optional | TransResults |  | Multi-Match (comma separated list) | When provided, limits the results to those transactions where the Response Code matches one of the provided filters. |
| Optional | UseMerchantTimeZone | boolean | Exact Match | When provided, setting the value to true will cause the API to display date time fields as the Time Zone configured for the merchant instead of the Eastern Time Zone default. |

Reporting API

Edit fields in the Pre-Request Script area to change what gets sent to BridgeComm..
Use the "Visualize" option to view the BridgeComm result.

Full Filter List

Get Transactions by Batch ID

Get Transactions by Merchant Account Code

Get Transactions by Merchant Code

Get Transactions by Organization ID

Get Transaction by Transaction ID

Get Transactions by Username

## Introduction

---

This API provides the ability to create and manage user and TokenPay credentials.

## Authentication

---

Each call to the Credentials Management API requires credentials. The Credentials object is used as a property of other objects in the API. The Credentials Object contains two properties: **UserName** and **Password**.

Both properties are strings.

Credentials Management API

User Management

TokenPay Credentials Management

Product Release Notes

API Release Notes

Authentication / Authorization Release Notes

Security Release Notes

Documentation Updates

Deprecation and Sunset Notices

Default

RH API

username

password

authenticationTokenId

tokenPayPrivateKey

Sandbox

Production

<p class="slate-p " ></p><h3 class="slate-h3 " ><a href="67ef553049745cb31c4444d9" target="">PayGuardian Cloud (Card Present Solutions) </a></h3><p class="slate-p " >PayGuardian Cloud makes payments weightless with no local software install! A true omni-channel solution for a merchant looking to solve for counter top or wireless devices, PCs or tablets, IOS or Android — it&apos;s all in our cloud solution. PG Cloud is highly scalable and allows the end user to view and manage all devices across multiple locations via our online portal.</p><p class="slate-p " >PayGuardian Cloud is Rectangle&apos;s web-based hosted service used to interact with EMV devices for securely processing transactions with your Point of Sale. The RESTful API allows for easy interactiosn via simple JSON requests. </p><p class="slate-p " ><strong class="slate-bold">Highlights include: </strong></p><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative">Hosted web services gives you the ability to POST a transaction request to any terminal at any location</div></li><li class="slate-li " ><div style="position:relative">Automated network discovery establishes and maintains a persistent connection to the gateway</div></li><li class="slate-li " ><div style="position:relative">Multiple registers and credit card terminals can be used simultaneously</div></li><li class="slate-li " ><div style="position:relative">Automates updates-no software installation necessary</div></li><li class="slate-li " ><div style="position:relative">PA-DSS compliant &amp; TLS 1.2</div></li><li class="slate-li " ><div style="position:relative">No access to sensitive card data</div></li></ul><p class="slate-p " ></p><h3 class="slate-h3 " ><a href="67ef553049745cb31c443d71" target="">Transaction API</a></h3><p class="slate-p " >The Rectangle Health Transaction API is a RESTful API for interfacing with the Rectangle Health Gateway. The API includes familiar transaction types from the BridgeComm API in a user friendly JSON interface.</p><p class="slate-p " >Rectangle Health&apos;s Transaction API can be used to process Card Not Present transactions. This API works in conjunction with both TokenPay.js and PayGuardian Cloud.</p><p class="slate-p " ></p><h3 class="slate-h3 " ><a href="67ef553149745cb31c444fd5" target="">TokenPay.js</a></h3><p class="slate-p " >TokenPay.js maximizes the user experience by allowing for the capture of sensitive card data within the payment form on the merchant&apos;s website. The consumer remains on the merchant&apos;s payment page at all times. </p><p class="slate-p " >TokenPay.js is an integration interface for the Payment Gateway that primarily facilitates online card payments in a manner that ensures that no sensitive card data ever needs to reach your servers so your integration can operate in a PCI compliant way. </p><p class="slate-p " >To ensure that merchants are eligible for the simplest PCI validation method, Self-Assessment Questionnaire (SAQ A)*, TokenPay.js utilizes:</p><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative"><strong class="slate-bold">Isolation </strong>— Payment Gateway hosts the card sensitive data input fields. The fields are injected into your form as an HTML iframe thus isolating your page and your server from card sensitive data.</div></li><li class="slate-li " ><div style="position:relative"><strong class="slate-bold">Tokenization </strong>— in order to execute transactions against the user&apos;s card, TokenPay.js tokenizes the card sensitive data. The card token is generated via the user of the TokenPay.js JavaScript library and your payment form. </div></li><li class="slate-li " ><div style="position:relative"><strong class="slate-bold">Segregation </strong>— Requests for charges against the user&apos;s card are made server-to-server not in the browser where it is publicly visible. The tokenized card data is submitted to your server where a secure server-to-server request is made to execute the transaction.</div></li><li class="slate-li " ><div style="position:relative"><strong class="slate-bold">Public/Private Keys </strong>— The injection of the TokenPay.js hosted input fields and card tokenization is authenticated via a public key assigned to the merchant. API requests to execute charges against the tokenized card information are made by the backend server and are authenticated with a private key assigned to the merchant. </div></li></ul><p class="slate-p " ></p><h3 class="slate-h3 " ><a href="67ef553049745cb31c444b58" target="">Wallet API</a></h3><p class="slate-p " >The Wallet API securely stores and manages customers&apos; payment information, including credit card details and bank account numbers. It employs tokenization to replace sensitive data with unique tokens, facilitating secure transactions without exposing actual payment details. </p><p class="slate-p " >Businesses can create customer profiles (customer wallets), enabling seamless checkout experiences and recurring billing. The API ensures compliance with PCI DSS while streamlining payment processing and providing a secure way to store sensitive payment details.</p><p class="slate-p " ></p><h3 class="slate-h3 " ><a href="67ef553149745cb31c444d5a" target="">Transaction Reporting API</a></h3><p class="slate-p " >The Transaction Reporting API allows a technology partner to offer their users the ability access transaction data for reporting purposes. This API enables providers to extract valuable insights from their data by retrieving their transaction history.</p><p class="slate-p " ></p><h3 class="slate-h3 " ><a href="67ef553149745cb31c444f50" target="">Credentials Management API</a></h3><p class="slate-p " >The Credentials Management API provides a secure and streamlined interface for creating, retrieving, and managing user and TokenPay credentials. This API enables technology partners to manage authentication credentials required for accessing resources and services. </p><p class="slate-p " >Whether you&apos;re onboarding new users, managing secure token-based accesss via TokenPay, or maintaining credential lifecycles, the Credential Management API offers a robust and scalable solution. </p><p class="slate-p " ></p><h3 class="slate-h3 " ></h3><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p>

PayGuardian Cloud makes payments weightless with no local software install! A true omni-channel solution for a merchant looking to solve for counter top or wireless devices, PCs or tablets, IOS or Android — it's all in our cloud solution. PG Cloud is highly scalable and allows the end user to view and manage all devices across multiple locations via our online portal.

PayGuardian Cloud is Rectangle's web-based hosted service used to interact with EMV devices for securely processing transactions with your Point of Sale. The RESTful API allows for easy interactiosn via simple JSON requests. 

The Rectangle Health Transaction API is a RESTful API for interfacing with the Rectangle Health Gateway. The API includes familiar transaction types from the BridgeComm API in a user friendly JSON interface.

Rectangle Health's Transaction API can be used to process Card Not Present transactions. This API works in conjunction with both TokenPay.js and PayGuardian Cloud.

TokenPay.js maximizes the user experience by allowing for the capture of sensitive card data within the payment form on the merchant's website. The consumer remains on the merchant's payment page at all times. 

TokenPay.js is an integration interface for the Payment Gateway that primarily facilitates online card payments in a manner that ensures that no sensitive card data ever needs to reach your servers so your integration can operate in a PCI compliant way. 

To ensure that merchants are eligible for the simplest PCI validation method, Self-Assessment Questionnaire (SAQ A)*, TokenPay.js utilizes:

The Wallet API securely stores and manages customers' payment information, including credit card details and bank account numbers. It employs tokenization to replace sensitive data with unique tokens, facilitating secure transactions without exposing actual payment details. 

Businesses can create customer profiles (customer wallets), enabling seamless checkout experiences and recurring billing. The API ensures compliance with PCI DSS while streamlining payment processing and providing a secure way to store sensitive payment details.

The Transaction Reporting API allows a technology partner to offer their users the ability access transaction data for reporting purposes. This API enables providers to extract valuable insights from their data by retrieving their transaction history.

The Credentials Management API provides a secure and streamlined interface for creating, retrieving, and managing user and TokenPay credentials. This API enables technology partners to manage authentication credentials required for accessing resources and services. 

Whether you're onboarding new users, managing secure token-based accesss via TokenPay, or maintaining credential lifecycles, the Credential Management API offers a robust and scalable solution. 

<p class="slate-p " >The User Guide section provides comprehensive instructions and guidelines for effectively utilizing the APIs within the project. Users can learn how to navigate the API&apos;s functionalities, understand its various features, and optimize their integration process for seamless operations. This section serves as a valuable resource for developers seeking clarity and guidance on leveraging the APIs to its full potential.</p><p class="slate-p " ></p>

The User Guide section provides comprehensive instructions and guidelines for effectively utilizing the APIs within the project. Users can learn how to navigate the API's functionalities, understand its various features, and optimize their integration process for seamless operations. This section serves as a valuable resource for developers seeking clarity and guidance on leveraging the APIs to its full potential.

<p class="slate-p " ></p><h2 class="slate-h2 " >Introduction</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >The TransactionAPI is a RESTful API for interfacing with the Gateway. The API includes familiar transaction types from the BridgeComm API in a user friendly JSON interface.</p><p class="slate-p " ></p><h2 class="slate-h2 " >Key Elements</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >The Transaction API request and response structure is made up of a core set of data elements plus specific objects and their sub-elements. Each object handles a subsection of API data elements like payment data, Healthcare, or Level II/III information elements. The core data elements are within the main request body and will include basic information like accountType, holderType, and transactionType.</p><p class="slate-p " >A list of all required and optional data elements can be found in each section.</p><p class="slate-p " >In the live environment, transactions must be initiated over an SSL-protected connection using a minimum of 128-bit encryption to protect sensitive data. Initial testing can be performed over an unencrypted connection; however, testing must be performed over an SSL-encrypted channel before a client can be certified to production. Only test card/ACH account data may be transmitted. No live payment information should ever be transmitted to the test system.</p><p class="slate-p " ></p><h2 class="slate-h2 " >Timeouts</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >The Transaction API has an internal timeout of 100 seconds. Integrating applications can expect all transactions to take less than 100 seconds, and if 100 seconds are exceeded without a response from the Transaction API, you may close your connection. If a transaction as attempted leveraging an invoiceNumber, you may use a Find Transaction request using your unique invoiceNumber to confirm the outcome of the transaction.</p><p class="slate-p " ></p><h2 class="slate-h2 " >Authentication Information</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >Each call to the Transaction API requires credentials; however, these credentials are not submitted in the request body. The <strong class="slate-bold">username</strong> and <strong class="slate-bold">password</strong> are values created in MyBridgePay, and they will be submitted in the request headers as Basic HTTP authentication.</p><p class="slate-p " >The Credentials object is used as a property of other objects in the API. The Credentials Object contains two properties: <strong class="slate-bold">username</strong> and <strong class="slate-bold">password.</strong></p><p class="slate-p " ></p><p class="slate-p " ></p>

The TransactionAPI is a RESTful API for interfacing with the Gateway. The API includes familiar transaction types from the BridgeComm API in a user friendly JSON interface.

The Transaction API request and response structure is made up of a core set of data elements plus specific objects and their sub-elements. Each object handles a subsection of API data elements like payment data, Healthcare, or Level II/III information elements. The core data elements are within the main request body and will include basic information like accountType, holderType, and transactionType.

A list of all required and optional data elements can be found in each section.

In the live environment, transactions must be initiated over an SSL-protected connection using a minimum of 128-bit encryption to protect sensitive data. Initial testing can be performed over an unencrypted connection; however, testing must be performed over an SSL-encrypted channel before a client can be certified to production. Only test card/ACH account data may be transmitted. No live payment information should ever be transmitted to the test system.

The Transaction API has an internal timeout of 100 seconds. Integrating applications can expect all transactions to take less than 100 seconds, and if 100 seconds are exceeded without a response from the Transaction API, you may close your connection. If a transaction as attempted leveraging an invoiceNumber, you may use a Find Transaction request using your unique invoiceNumber to confirm the outcome of the transaction.

Each call to the Transaction API requires credentials; however, these credentials are not submitted in the request body. The 

 are values created in MyBridgePay, and they will be submitted in the request headers as Basic HTTP authentication.

The Credentials object is used as a property of other objects in the API. The Credentials Object contains two properties: 

The TransactionAPI is a RESTful API for interfacing with the Gateway. The API includes familiar transaction types from the BridgeComm API

<p class="slate-p " >The following section contains examples of Card Not Present transactions through the Transaction API. A card not present transaction is defined as a transaction in which the card data was not directly read off of the card and instead manually keyed into a program, web page, or virtual terminal. The card information is then formatted into a Transaction API request and used to process a transaction.</p><p class="slate-p " >It is recommended that card data collected on a web page be collected using BridgePay&apos;s TokenPay.js product. See the TokenPay.js folder for more information.</p><p class="slate-p " ></p><p class="slate-p " ></p>

The following section contains examples of Card Not Present transactions through the Transaction API. A card not present transaction is defined as a transaction in which the card data was not directly read off of the card and instead manually keyed into a program, web page, or virtual terminal. The card information is then formatted into a Transaction API request and used to process a transaction.

It is recommended that card data collected on a web page be collected using BridgePay's TokenPay.js product. See the TokenPay.js folder for more information.

<p class="slate-p " >The following section outlines the various non-transaction functions provided by the gateway.</p><p class="slate-p " ></p><p class="slate-p " ></p>

<p class="slate-p " >The following section outlines how to process a Capture transaction using the Transaction API.</p><p class="slate-p " ></p>

The following section outlines how to process a Capture transaction using the Transaction API.

Capture

<p class="slate-p " >The following section outlines how to submit a Find Transaction request using the Transaction API. This allows a user to pull transaction details by providing an invoice number or gateway transaction ID.</p><p class="slate-p " ></p>

The following section outlines how to submit a Find Transaction request using the Transaction API. This allows a user to pull transaction details by providing an invoice number or gateway transaction ID.

Find Transaction

<p class="slate-p " >The following section outlines the GET Merchant Information functionality of the Transaction API. It is used to return merchant information related to the authorization credentials.</p><p class="slate-p " ></p>

The following section outlines the GET Merchant Information functionality of the Transaction API. It is used to return merchant information related to the authorization credentials.

Get Merchant Info

<p class="slate-p " >The GET MerchantInfo request will return the Merchant Account Information related to the credentials used for authorization. Please note that only merchant account user credentials can be used for this endpoint.</p><p class="slate-p " ></p><p class="slate-p " ></p>

The GET MerchantInfo request will return the Merchant Account Information related to the credentials used for authorization. Please note that only merchant account user credentials can be used for this endpoint.

Get Merchant Information

Authorization

gatewayResult

merchantCode

merchantName

merchantAccountCode

organizationId

requestType

responseCode

responseDescription

metadata

<p class="slate-p " >The following section outlines how to process a manual Settlement using the Transaction API.</p><p class="slate-p " >Settlement can also be automated via the virtual terminal. This is only required if settlement is intended to be triggered by the integrated solution.</p><h2 class="slate-h2 " >Request Information</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >The following table outlines the available data elements for Settlement endpoint.</p><div class="table-container" style="width:100%;min-width:100%"><table class="slate-table" style="min-width:100%"><div class="published-table-header" style="width:100%;min-width:100%;min-height:initial;visibility: hidden;border:initial"><div style="width:100px;">Title</div><div style="width:100px;">Description</div><div style="width:100px;">Title</div><div style="width:100px;">Description</div><div style="width:100px;">Title</div></div><colgroup ><col style="width:initial"><col style="width:initial"></colgroup><tbody class="slate-TableElement-tbody"><tr class="slate-tr " ><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " >Condition</p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " >Data Element</p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " >Data Type</p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " >Length</p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " >Description</p></td></div></tr><tr class="slate-tr " ><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " >Required</p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " >merchantAccountCode</p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " >string</p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " ></p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " >The Merchant Account Code assigned to the merchant gateway at time of boarding.</p></td></div></tr><tr class="slate-tr " ><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " >Optional</p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " >memo</p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " >string</p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " >60</p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " >User supplied data.</p></td></div></tr></tbody></table></div><p class="slate-p " ></p><p class="slate-p " ></p>

The following section outlines how to process a manual Settlement using the Transaction API.

Settlement can also be automated via the virtual terminal. This is only required if settlement is intended to be triggered by the integrated solution.

The following table outlines the available data elements for Settlement endpoint.

Title

Description

Settlement

<p class="slate-p " ></p><h2 class="slate-h2 " >Overview</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >The TokenPay.js provides users to securely collect card information and execute transaction in a PCI compliant manner. The base integration solutions for TokenPay.js include: </p><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative">TransactionAPI - a web services API for payment processing. The use of Transaction API (without TokenPay.js) for payment capture places 100% of PCI Compliance responsibility on the Customer&apos;s integration</div></li><li class="slate-li " ><div style="position:relative">TokenPay.js - is an extension of the Transaction API that combines client-side and server-side technologies for PCI-compliant online payment capture.</div></li></ul><p class="slate-p " >TokenPay.js maximizes the user experience by allowing for the capture of sensitive card data within the payment form on the merchant&apos;s website. The consumer remains on the merchant&apos;s payment page at all times. The payment ‘token’ is only valid for use within 15 minutes of being generated or until used for the Transaction API transaction.</p><p class="slate-p " >TokenPay.js is an integration interface for the Payment Gateway that primarily facilitates online card payments in a manner that ensures that no sensitive card data ever needs to reach your servers so your integration can operate in a PCI compliant way. </p><p class="slate-p " >To ensure that merchants are eligible for the simplest PCI validation method, Self-Assessment Questionnaire (SAQ A)*, TokenPay.js utilizes: </p><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative">Isolation - Payment Gateway hosts the card sensitive data input fields. The fields are injected into your form as an HTML iframe thus isolating your page and your server from card sensitive data.</div></li><li class="slate-li " ><div style="position:relative">Tokenization - in order to execute transactions against the user&apos;s card, TokenPay.js tokenizes the card sensitive data. The card token is generated via the use of the TokenPay.js JavaScript library and your payment form. </div></li><li class="slate-li " ><div style="position:relative">Public/Private Keys - The injection of the TokenPay.js hosted input fields and card tokenization is authenticated via a public key assigned to the merchant. API requests to execute charges against the tokenized card information are made by the backend server and are authenticated with a private key assigned to the merchant. </div></li><li class="slate-li " ><div style="position:relative">If you are processing more than six million transactions per year, you are not eligible to use a SAQ to prove PCI compliance. Payment brands require you to complete a Report on Compliance (RoC) to validate your PCI compliance annually.</div></li></ul><p class="slate-p " ></p><h2 class="slate-h2 " >Authentication</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >TokenPay.js transactions will not use Basic Authorization like other transaction types in the Transaction API. To authenticate a TokenPay.js transaction, Basic Authorization must be disabled and an Authorization header must be included. </p><p class="slate-p " >The Authorization header value is a combination of a static text value (TokenPay) and a base64 encoded combination of the AuthenticationTokenID and the TokenPay.js PrivateKey separated by a colon (:). Examples of how this is achieved are provided in this collection, and the process for compiling is exemplified in the pre-request script for these examples. </p><p class="slate-p " >Below is an example of the raw and Base64 encoded values:</p><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative">RAW: TokenPay f5021ddf-afe1-4db6-961c-a65185e79d13:TtXNMYZUXRSZWfw4</div></li><li class="slate-li " ><div style="position:relative">Base64: TokenPay ZjUwMjFkZGYtYWZIMS00ZGI2LTk2MWMtYTY1MTg1ZTc5ZDEzOIR0WE5NWVpVWFJTWIdmdzQ=</div></li></ul><p class="slate-p " ></p><h2 class="slate-h2 " >Client Side</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >TokenPay.js is the JavaScript library for building payment flows within the Payment Gateway. With it you can collect card sensitive data from the user and create payment tokens for securely sending the data to your server in a PCI compliant manner. </p><p class="slate-p " >TokenPay.js provides a ready-made UI component for collecting the card sensitive data from the user. TokenPay.js then tokenizes the information without ever having to touch your server.</p><p class="slate-p " >The TokenPay.js UI component includes:</p><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative">Automatically format card information as it is entered</div></li><li class="slate-li " ><div style="position:relative">Validation of card information as it is entered</div></li><li class="slate-li " ><div style="position:relative">Responsive Design that works on user&apos;s screen or mobile device</div></li><li class="slate-li " ><div style="position:relative">Customizable styling to match your look and feel</div></li></ul><p class="slate-p " ></p><h2 class="slate-h2 " >Payment Form Submission Best Practices</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >When implementing payment forms, it is recommended that the integrator utilize reCAPTCHA. reCAPTCHA protects payment forms from SPAM and bot abuse. Using reCAPTCHA on your payment forms reduces the risk of fraudulent transactions on the merchant&apos;s eCommerce sites by performing a Completely Automated Public Turing Test to Tell Computers and Humans Apart (CAPTCHA) test to tell humans and bots apart.</p><p class="slate-p " >For more information on reducing form SPAM and bot abuse visit: <a href="https://developers.google.com/recaptcha/intro" target="_self">https://developers.google.com/recaptcha/intro</a></p><p class="slate-p " ></p><h2 class="slate-h2 " >Public and Private Keys</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >When a Payment Gateway Merchant using the Transaction API wants to utilize TokenPay.js for online transactions, a public/private key pair is assigned to the merchant for use with TokenPay.js. The public/private key is tied to a merchant account and merchant account code combination.</p><p class="slate-p " >The public key is utilized by the TokenPay.js JavaScript library on your payment web page and is publicly visible, but this key only allows for the injection of the Payment Gateway hosted input fields. This key cannot be used to execute transactions against the user&apos;s card. </p><p class="slate-p " >The private key MUST be secured and never shared. The combination of the TokenPay.js generated card payment token and private key allows for charges to be made against the associated user&apos;s card. </p><p class="slate-p " ></p><h2 class="slate-h2 " >HTTP Requirements</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >All submission of payment information using TokenPay.js is made via a secure HTTPS connection. To protect yourself from man-in-the-middle attacks and to prevent your users from experiencing mixed content warnings in their browser, you <strong class="slate-bold">MUST </strong>server the page with your payment form over <strong class="slate-bold">HTTPS</strong>.</p><p class="slate-p " >The URL of the page containing TokenPay.js MUST begin with https://</p><p class="slate-p " ><strong class="slate-bold">&lt; Test URL &gt;</strong></p><p class="slate-p " ><a href="https://rhuat.bridgepaynetsecuretest.com/WebSecurity/TokenPay/plain-js/tokenPay.js" target="_self">https://rhuat.bridgepaynetsecuretest.com/WebSecurity/TokenPay/plain-js/tokenPay.js</a></p><p class="slate-p " ><strong class="slate-bold">&lt; Production URL &gt;</strong></p><p class="slate-p " ><a href="https://api.rectanglehealth.com/WebSecurity/TokenPay/plain-js/tokenPay.js" target="_self">https://api.rectanglehealth.com/WebSecurity/TokenPay/plain-js/tokenPay.js</a></p><p class="slate-p " ></p><h4 class="slate-h4 " ><strong class="slate-bold">Step 1: Setting Up TokenPay.js</strong></h4><p class="slate-p " >To get started, include this script on your page (sample code is using the Test URL):</p><div class="code-block-wrapper"  style="width:100%;min-width:100%" ><div class="code-block-header">HTML</div><pre class="slate-CodeBlockElement slate-code_block"><textarea id="publishedPageCodeblock" style="display:none !important; visibility: hidden; opacity: 0; width: 1px; height: 1px;" type="hidden"><html>
<head>
   <title>Payment</title>
   <script type="text/javascript" src="https://www.bridgepaynetsecuretest.com/WebSecurity/TokenPay/plain-js/tokenpay.js"></script>
   <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css" integrity="sha384-BVYiiSIFeK1dGmJRAkycuHAHRg32OmUcww7on3RYdg4Va+PmSTsz/K68vbdEjh4u" crossorigin="annoymous">
   <style>
       #amount {
           width: 75px;
       }
   </style>
</head> </textarea><code class="language-html keep-markup drop-tokens"></code></pre></div><h4 class="slate-h4 " >Step 2: Create Your Payment Form</h4><p class="slate-p " >To securely collect card sensitive details from your users, TokenPay.js creates UI components for you that are hosted by gateway. They are then inserted into your payment form.</p><p class="slate-p " >To determine where to insert the UI components, create empty DOM elements with unique IDs within your payment form. If you want to modify and customize the style of the card entry area, create a hidden element to contain your styling. The id of this element MUST be ‘customStyles’. </p><div class="code-block-wrapper"  style="width:100%;min-width:100%" ><div class="code-block-header">HTML</div><pre class="slate-CodeBlockElement slate-code_block"><textarea id="publishedPageCodeblock" style="display:none !important; visibility: hidden; opacity: 0; width: 1px; height: 1px;" type="hidden"><body>
<form id="paymentForm" action="rhuat.bridgepaynetsecuretest.com/WebSecurity/echo.aspx" method="post" style="margin: 10px">
    <select class="form-control" name="amount" id="amount" style="width:100px;">
         <option value="25">$25</option>
         <option value="50">$50</option>
    </select>
    <div id="card" style="border: solid 1px red; min=height: 200px; width: 470px; padding: 20px 10px; border-radius: 10px; margin: 10px 0px;"></div>
    <div id="errorMessage" style="margin-bottom: 10px; color: #c0392b;"></div>
    <button type="submit" class="btn btn-default">Submit</button>
</form> </textarea><code class="language-html keep-markup drop-tokens"></code></pre></div><p class="slate-p " >When the form is loaded, initialize the Pay element: </p><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative">Replace the phrase your-public-key, shown below, with your publishable public key tied to your merchant account and merchant account codes. </div></li><li class="slate-li " ><div style="position:relative">To display ACH instead of credit card fields set ‘eACH’ to ‘true’. </div></li><li class="slate-li " ><div style="position:relative">To disable zip code field (prevent zip code field from displaying) set ‘disableCVV’ to ‘true’ </div></li></ul><div class="code-block-wrapper"  style="width:100%;min-width:100%" ><div class="code-block-header">HTML</div><pre class="slate-CodeBlockElement slate-code_block"><textarea id="publishedPageCodeblock" style="display:none !important; visibility: hidden; opacity: 0; width: 1px; height: 1px;" type="hidden"><script>
   var tokenpay = TokenPay('tokenpay22725api20250527120554796');
   tokenpay.initialize({
        dataElement: ‘card’,
        errorElement: ‘errorMessage’,
        amountElement: ‘amount’,
        useACH: false,
        useStyles: false,
        disableZip: false,
        disableCvv: false
    });
     </textarea><code class="language-html keep-markup drop-tokens"></code></pre></div><p class="slate-p " >The TokenPay element simplifies the form and minimizes the fields required by inserting a single input field that securely collects all needed card data. </p><p class="slate-p " >If you have created the customStyles element to style the card entry area, change the value of ‘useStyles’ to ‘true’. </p><h4 class="slate-h4 " >Step 3: Submit the Token</h4><p class="slate-p " >The card data collected by the TokenPay element returns a payment token to be used with the private key for the transaction request to the Transaction API. If there are any errors in the collection of the card data or creation of the payment token, information is automatically displayed in the ‘errorElement’ of your payment form.</p><div class="code-block-wrapper"  style="width:100%;min-width:100%" ><div class="code-block-header">HTML</div><pre class="slate-CodeBlockElement slate-code_block"><textarea id="publishedPageCodeblock" style="display:none !important; visibility: hidden; opacity: 0; width: 1px; height: 1px;" type="hidden">var form = 
document.getElementById
('paymentForm);
    
form.addEventListener
('submit', function(event) {
        event.preventDefault();
        tokenpay.createToken(function (result) {
            var hiddenInput = document.createElement('input');
            hiddenInput.setAttribute('type', ‘hidden’);
            hiddenInput.setAttribute('name', ‘token’);
            hiddenInput.setAttribute('value', result.token);
            form.appendChild(hiddenInput);
            form.submit();
        }, function (result) {
            console.log("error: " + result);
        });
    });
</script>
</body>
</html> </textarea><code class="language-html keep-markup drop-tokens"></code></pre></div><p class="slate-p " ></p><h2 class="slate-h2 " >Server Side</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >Once you have securely collected and tokenized your user&apos;s card payment data using TokenPay.js, you will have a 15 minutes window in which to complete the transaction request. The payment token expires after the 15 minutes window or when used. </p><p class="slate-p " >To complete the transaction, you must perform a sale, validation or multi-use token request in a call to the Transaction API. </p><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p>

The TokenPay.js provides users to securely collect card information and execute transaction in a PCI compliant manner. The base integration solutions for TokenPay.js include: 

TokenPay.js maximizes the user experience by allowing for the capture of sensitive card data within the payment form on the merchant's website. The consumer remains on the merchant's payment page at all times. The payment ‘token’ is only valid for use within 15 minutes of being generated or until used for the Transaction API transaction.

To ensure that merchants are eligible for the simplest PCI validation method, Self-Assessment Questionnaire (SAQ A)*, TokenPay.js utilizes: 

TokenPay.js transactions will not use Basic Authorization like other transaction types in the Transaction API. To authenticate a TokenPay.js transaction, Basic Authorization must be disabled and an Authorization header must be included. 

The Authorization header value is a combination of a static text value (TokenPay) and a base64 encoded combination of the AuthenticationTokenID and the TokenPay.js PrivateKey separated by a colon (:). Examples of how this is achieved are provided in this collection, and the process for compiling is exemplified in the pre-request script for these examples. 

Below is an example of the raw and Base64 encoded values:

TokenPay.js is the JavaScript library for building payment flows within the Payment Gateway. With it you can collect card sensitive data from the user and create payment tokens for securely sending the data to your server in a PCI compliant manner. 

TokenPay.js provides a ready-made UI component for collecting the card sensitive data from the user. TokenPay.js then tokenizes the information without ever having to touch your server.

When implementing payment forms, it is recommended that the integrator utilize reCAPTCHA. reCAPTCHA protects payment forms from SPAM and bot abuse. Using reCAPTCHA on your payment forms reduces the risk of fraudulent transactions on the merchant's eCommerce sites by performing a Completely Automated Public Turing Test to Tell Computers and Humans Apart (CAPTCHA) test to tell humans and bots apart.

For more information on reducing form SPAM and bot abuse visit: 

When a Payment Gateway Merchant using the Transaction API wants to utilize TokenPay.js for online transactions, a public/private key pair is assigned to the merchant for use with TokenPay.js. The public/private key is tied to a merchant account and merchant account code combination.

The public key is utilized by the TokenPay.js JavaScript library on your payment web page and is publicly visible, but this key only allows for the injection of the Payment Gateway hosted input fields. This key cannot be used to execute transactions against the user's card. 

The private key MUST be secured and never shared. The combination of the TokenPay.js generated card payment token and private key allows for charges to be made against the associated user's card. 

All submission of payment information using TokenPay.js is made via a secure HTTPS connection. To protect yourself from man-in-the-middle attacks and to prevent your users from experiencing mixed content warnings in their browser, you 

server the page with your payment form over 

The URL of the page containing TokenPay.js MUST begin with https://

To get started, include this script on your page (sample code is using the Test URL):

To securely collect card sensitive details from your users, TokenPay.js creates UI components for you that are hosted by gateway. They are then inserted into your payment form.

To determine where to insert the UI components, create empty DOM elements with unique IDs within your payment form. If you want to modify and customize the style of the card entry area, create a hidden element to contain your styling. The id of this element MUST be ‘customStyles’. 

When the form is loaded, initialize the Pay element: 

The TokenPay element simplifies the form and minimizes the fields required by inserting a single input field that securely collects all needed card data. 

If you have created the customStyles element to style the card entry area, change the value of ‘useStyles’ to ‘true’. 

The card data collected by the TokenPay element returns a payment token to be used with the private key for the transaction request to the Transaction API. If there are any errors in the collection of the card data or creation of the payment token, information is automatically displayed in the ‘errorElement’ of your payment form.

Once you have securely collected and tokenized your user's card payment data using TokenPay.js, you will have a 15 minutes window in which to complete the transaction request. The payment token expires after the 15 minutes window or when used. 

To complete the transaction, you must perform a sale, validation or multi-use token request in a call to the Transaction API. 

The TokenPay.js provides users to securely collect card information and execute transaction in a PCI compliant manner. The base integration so

<p class="slate-p " >

## Overview



---
PayGuardian Cloud is a web-based hosted service used to interact with EMV devices for securely processing transactions with your Point of Sale. The RESTful API allows for easy interactions via simple JSON requests.

Highlights include:

- Hosted web services gives you the ability to POST a transaction request to any terminal at any location
    
- Automated network discovery establishes and maintains a persistent connection to the gateway
    
- Multiple registers and credit card terminals can be used simultaneously
    
- Automates updates-no software installation necessary
    
- PA-DSS compliant &amp; TLS 1.2
    
- No access to sensitive card data
   </p><p class="slate-p " >

## Connection Strings

---

**&lt; TEST &gt;**



The **mode** key should always be set to UAT when POSTing to this URL.

**&lt; PRODUCTION &gt;**



The **mode** key should always be set to PROD when POSTing to this URL</p><p class="slate-p " >

## Key Elements

---

### Prerequisites

Before continuing, you should have test merchant account credentials and a Cloud certified device.

### Devices

Terminals intended for use in production must be injected with the Production Rectangle Health P2PE key.  
Terminals intended for use in UAT must be injected with the Test Rectangle Health P2PE key. Please reach out to Payments ([payments@rectanglehealth.com](https://mailto:payments@rectanglehealth.com)) for key  
information.

##### &lt; PAX &gt;

PAX A Series devices are WiFi enabled and complete the same integration process for PG Cloud. The A Series requires a download of the PayGuardian Cloud Mobile App from the PAXStore to load onto the device. For PAXStore access or app related issues, please email \[[paxstore.support@pax.us](https://mailto:paxstore.support@pax.us)\](mailto: [paxstore.support@pax.us](https://mailto:paxstore.support@pax.us)). PAX requires anyone using their device to be registered with the PAXStore.

The following PAX A Series devices are currently supported:

- A920 Max
    
- A80
    
- A800
    

##### &lt; Ingenico &gt;

Ingenico Tetra Lane devices are ethernet based processing terminals and require basic configuration to install PayGuardian Cloud.  
The following Ingenico Tetra Series devices are currently supported.

- Lane 3000
    
- Lane 7000</p><p class="slate-p " >
    

## Process Flow

---

PayGuardian Cloud acts as middleware to save the integrator from interfacing directly with the device itself. The process flow is a simple request and response; however, the request  
will trigger the device to prompt for the card and process the transaction.  
Once the transaction is processed, the response data is fed back up the chain to the gateway and the integrated POS system.</p><p class="slate-p " >

## Authentication Information

---

Each request to PayGuardian cloud requires credentials to authorize. These values are defined in full in the Request and Response information section, and they are listed below:

- username
    
- password
    
- merchantAccountCode
    
- merchantCode
    
</p><p class="slate-p " ></p><p class="slate-p " ></p>



## Overview



---
PayGuardian Cloud is a web-based hosted service used to interact with EMV devices for securely processing transactions with your Point of Sale. The RESTful API allows for easy interactions via simple JSON requests.

Highlights include:

- Hosted web services gives you the ability to POST a transaction request to any terminal at any location
    
- Automated network discovery establishes and maintains a persistent connection to the gateway
    
- Multiple registers and credit card terminals can be used simultaneously
    
- Automates updates-no software installation necessary
    
- PA-DSS compliant & TLS 1.2
    
- No access to sensitive card data
   



## Connection Strings

---

**< TEST >**



The **mode** key should always be set to UAT when POSTing to this URL.

**< PRODUCTION >**



The **mode** key should always be set to PROD when POSTing to this URL



## Key Elements

---

### Prerequisites

Before continuing, you should have test merchant account credentials and a Cloud certified device.

### Devices

Terminals intended for use in production must be injected with the Production Rectangle Health P2PE key.  
Terminals intended for use in UAT must be injected with the Test Rectangle Health P2PE key. Please reach out to Payments ([payments@rectanglehealth.com](https://mailto:payments@rectanglehealth.com)) for key  
information.

##### < PAX >

PAX A Series devices are WiFi enabled and complete the same integration process for PG Cloud. The A Series requires a download of the PayGuardian Cloud Mobile App from the PAXStore to load onto the device. For PAXStore access or app related issues, please email \[[paxstore.support@pax.us](https://mailto:paxstore.support@pax.us)\](mailto: [paxstore.support@pax.us](https://mailto:paxstore.support@pax.us)). PAX requires anyone using their device to be registered with the PAXStore.

The following PAX A Series devices are currently supported:

- A920 Max
    
- A80
    
- A800
    

##### < Ingenico >

Ingenico Tetra Lane devices are ethernet based processing terminals and require basic configuration to install PayGuardian Cloud.  
The following Ingenico Tetra Series devices are currently supported.

- Lane 3000
    
- Lane 7000


    

## Process Flow

---

PayGuardian Cloud acts as middleware to save the integrator from interfacing directly with the device itself. The process flow is a simple request and response; however, the request  
will trigger the device to prompt for the card and process the transaction.  
Once the transaction is processed, the response data is fed back up the chain to the gateway and the integrated POS system.



## Authentication Information

---

Each request to PayGuardian cloud requires credentials to authorize. These values are defined in full in the Request and Response information section, and they are listed below:

- username
    
- password
    
- merchantAccountCode
    
- merchantCode
    


PayGuardian Cloud is a web-based hosted service used to interact with EMV devices for securely processing transactions with your

<p class="slate-p " ></p><h2 class="slate-h2 " >Introduction</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >The Wallet API provides the ability to create and manage wallet views usable.</p><p class="slate-p " ></p><h2 class="slate-h2 " >Construct</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >Components that make up the structure on the Wallet API and its usage.</p><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative"><strong class="slate-bold">WalletSite</strong> - a collection of wallets. It is agnostic in that it has no requirement to be associated with any given merchant account, merchant group, or reseller. It can also be shared among multiple merchant accounts, belonging to multiple merchant groups, and even resellers.</div></li><li class="slate-li " ><div style="position:relative"><strong class="slate-bold">Wallet</strong> - a wallet belongs to a wallet site and represents a single payment method (Credit Card/ACH).</div></li><li class="slate-li " ><div style="position:relative"><strong class="slate-bold">Payment Method</strong> - contains all the necessary information to perform a transaction (Token, Expiration Date/Routing Number) and AVS information.</div></li><li class="slate-li " ><div style="position:relative"><strong class="slate-bold">Merchant Account Subscribes to a Wallet Site</strong> - multiple merchant accounts can subscribe to the same wallet site (effectively sharing payment information data), but one merchant account cannot subscribe to multiple wallet sites.</div></li><li class="slate-li " ><div style="position:relative"><strong class="slate-bold">Contract in Recurring Billing</strong> - exists between a merchant account and a customer of the merchant account.</div></li><li class="slate-li " ><div style="position:relative"><strong class="slate-bold">Customer Account</strong> - describes the customer (one of the parties in the contract)</div></li><li class="slate-li " ><div style="position:relative"><strong class="slate-bold">Financially Responsible Party</strong> - a person or business that has access to one or more wallets. A customer account can have multiple financially responsible parties</div></li></ul><p class="slate-p " ></p><h2 class="slate-h2 " >Order of Process Flow</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >The order in which each Wallet API component must be created or used is below.</p><p class="slate-p " ><strong class="slate-bold">1. Create a WalletView</strong></p><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative">Use CreateWalletView endpoint to create a new Wallet.</div></li></ul><p class="slate-p " ><strong class="slate-bold">2. Get all the Wallet Details</strong></p><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative">Use WalletView Model endpoints to get the details for the created wallet.</div></li></ul><p class="slate-p " ><strong class="slate-bold">3. Call Transaction API with the Wallet Details</strong></p><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative">Call Transaction API using the relevant data elements instead of using Token, Card Number, Expiration Date, Bank Account Number, Routing Number, etc. For Transaction API, use walletPaymentMethodId and customerWalletId.</div></li></ul><p class="slate-p " ></p><h2 class="slate-h2 " >Authentication</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >Each call to the Wallet API requires credentials. The Credentials object is used as a property of other objects in the API. The Credentials Object contains two properties: <strong class="slate-bold">UserName</strong> and <strong class="slate-bold">Password</strong>.</p><p class="slate-p " >Both properties are strings.</p><p class="slate-p " ></p><h2 class="slate-h2 " >Testing and Integration Support</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >In the live environment, transactions must be initiated over an SSL-protected connection using a minimum of 128-bit encryption to protect sensitive data. Initial testing can be performed over an unencrypted connection; however, testing must be performed over an SSL-encrypted channel before a client can be certified to production. Only test card/ACH account data may be transmitted -<em class="slate-italic">no live payment information should ever be transmitted to the test system.</em></p><p class="slate-p " >You may use the following test payment account information in testing:</p><div class="table-container" style="width:98%;
  min-width:98%;"><table class="slate-table" style="min-width:100%"><div class="published-table-header" style="width:100%;min-width:100%;min-height:initial;visibility: hidden;border:initial"><div style="width:100px;">Title</div><div style="width:100px;">Description</div><div style="width:100px;">Title</div><div style="width:100px;">Description</div><div style="width:100px;">Title</div></div><colgroup ><col style="width:initial"><col style="width:initial"></colgroup><tbody class="slate-TableElement-tbody"><tr class="slate-tr " ><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " ><strong class="slate-bold">Payment Type</strong></p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " ><strong class="slate-bold">Token</strong></p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " ><strong class="slate-bold">Routing Number</strong></p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " ><strong class="slate-bold">Expiry Date</strong></p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " ><strong class="slate-bold">Security Code</strong></p></td></div></tr><tr class="slate-tr " ><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " >MasterCard</p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " >5439750001500347</p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " ></p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " ></p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " ></p></td></div></tr><tr class="slate-tr " ><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " >Visa</p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " >4005550000000019</p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " ></p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " ></p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " ></p></td></div></tr><tr class="slate-tr " ><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " >Discover</p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " >60011111111111117</p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " ></p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " ></p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " ></p></td></div></tr><tr class="slate-tr " ><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " >Diners</p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " >36999999999999</p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " ></p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " ></p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " ></p></td></div></tr><tr class="slate-tr " ><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " >AMEX</p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " >374255312721002</p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " ></p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " ></p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " ></p></td></div></tr><tr class="slate-tr " ><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " >ACH</p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " >11110000000000279992</p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " >021000021</p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " ></p></td></div><div class="slate-TableCellElement-content"><td class="slate-td"><p class="slate-p " ></p></td></div></tr></tbody></table></div><p class="slate-p " ></p><p class="slate-p " ></p>

The Wallet API provides the ability to create and manage wallet views usable.

Components that make up the structure on the Wallet API and its usage.

The order in which each Wallet API component must be created or used is below.

3. Call Transaction API with the Wallet Details

Each call to the Wallet API requires credentials. The Credentials object is used as a property of other objects in the API. The Credentials Object contains two properties: 

In the live environment, transactions must be initiated over an SSL-protected connection using a minimum of 128-bit encryption to protect sensitive data. Initial testing can be performed over an unencrypted connection; however, testing must be performed over an SSL-encrypted channel before a client can be certified to production. Only test card/ACH account data may be transmitted -

no live payment information should ever be transmitted to the test system.

You may use the following test payment account information in testing:

The Wallet API provides the ability to create and manage wallet views usable.ConstructComponents that make up the structure on the Wallet

The Transaction Reporting API allows users to retrieve transaction data through a SOAP request made to the service. Users can include parameters in the SOAP method to filter the data and receive a response containing the requested information.

Skip and Take fields are required when calling the API. Transaction Rows and Batch Details will be limited to 1000 at a time. Using take and Skip you can obtain larger data sets in multiple calls. For instance, if 1,500 records are available based on the filter information sent in, the first 1000 records would be obtained by sending in 1000 for Take and 0 for skip. The next 500 records would be obtained by sending in Take for 500 and skip for 1000.

Credentials are required to access the Transaction Reporting API.

The following table outlines the available data elements for filtering the transaction data.

Condition

Data Element

Date Type

Validations

The Transaction Reporting API allows users to retrieve transaction data through a SOAP request made to the service. Users can include para

<p class="slate-p " ></p><h2 class="slate-h2 " >Introduction</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >This API provides the ability to create and manage user and TokenPay credentials.</p><p class="slate-p " ></p><h2 class="slate-h2 " >Authentication</h2><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >Each call to the Credentials Management API requires credentials. The Credentials object is used as a property of other objects in the API. The Credentials Object contains two properties: <strong class="slate-bold">UserName</strong> and <strong class="slate-bold">Password</strong>.</p><p class="slate-p " >Both properties are strings.</p><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p>

This API provides the ability to create and manage user and TokenPay credentials.

Each call to the Credentials Management API requires credentials. The Credentials object is used as a property of other objects in the API. The Credentials Object contains two properties: 

Sections