Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 39 Next »

Introduction

View this guide in Postman: https://documenter.getpostman.com/view/19035881/2s93m7VgE9

Overview

The BridgeComm Communication API provides an Internet-facing web services interface for requesting a variety of payment related services in real-time. The interface is a Windows Communication Foundation (WCF) web service using the request/response architecture. It provides four access methods that allow for different formatting options for interacting with the core communication library, and the ability to request a one-time purchase token for more secure access:

Access Method

Description

String ProcessRequest(string requestMsg)

(http://url/PaymentService/RequestHandler.svc)

This access method accepts a base64 encoded XML formatted request message and returns a base64 encoded XML formatted response.

string ProcessMessage

(https://url/PaymentService/Default.aspx)

This access method accepts an HTML formatted query string with parameters and returns an HTML formatted response, transformed by a client selected XSLT transform.

string AcquirePurchaseToken(string userName, string password, string certificationId, int transactionAmount, string purchaserInfo, string transactionInfo)

(https://url/PaymentService/ActionService.svc)

This access method accesses specific parameters to pre-authenticate a purchase. When used, the non-sensitive details of a transaction are used to create a one-time purchase token that can be sent with the transaction request. A GUID
defining the purchase token is returned upon a successful request.

Response ProcessCreditCard(string UserName, string TransType, string CardNum, string ExpDate, string MagData, string NameOnCard, string Amount, string InvNum, string PNRef, string ZIP, string Street, string CVNum, string ExtData)

(https://url/PaymentService/TPIRequestHandler.asmx)

This access method provides limited functionality for migrating from the legacy TPI gateway to the new BridgePay gateway. This method must not be used for new integrations, especially for those interested in using EMV.

NEW REST Interface

The BridgePay Transaction API is a RESTful API for interfacing with the BridgePay Gateway for both card present and card not present transaction processing. The API includes familiar transaction types from the BridgeComm API in a user friendly JSON interface. The documentation for this API can be found here

Note: As a prerequisite to use the Transaction API for card present transactions, an integrator must perform a direct integration to their intended card reader in order to read and obtain the card data and format it into a Transaction API request. A direct integration may be performed to devices BridgePay has certified with our processors. Please view the certified devices list for clarity. 

Merchant Credentials

In your welcome package, you should receive the combination of Merchant Code and Merchant Account Code to be used as merchant credentials in most transaction and lookup requests, once your account has been established.

To include this information in a request to BridgeComm, you will simply include them as another set of fields in the request message itself. To add them to the request, simply place them anywhere in the body of the requestMessage element, prior to Base64 encoding. See the example below with the Merchant Code and Merchant Account Codes highlighted.
 

XML Request Message

<?xml version="1.0" encoding="utf-16"?>
  <requestHeader>
	<ClientIdentifier>SOAP</ClientIdentifier>
	<TransactionID>123456789</TransactionID>
	<RequestType>004</RequestType>
	<RequestDateTime>20200528120822</RequestDateTime>
	<User>bpntest</User>
	<Password>57!sE@3Fm</Password>
	  <requestMessage>
        .
        .
        .
        <MerchantCode>575000</MerchantCode>
		<MerchantAccountCode>575004</MerchantAccountCode>
       .
       . 
       .       
     </requestMessage>
  </requestHeader>

Note that not every request type requires this information and not every request type requires these exact fields. Be sure to work with your BridgePay representative when determining which message types require the merchant lookup fields and their content.
 

Pass-Through Fields

In addition, the service request system supports the submission of extraneous, non-payment data elements that are submitted specifically as “pass through” information to be used for reporting and accounting purposes. These elements may include items like: invoice number, operator ID, service code, or any other reporting data that an interfacing system might need.
 

Request/Response Structure

Requests are formatted and sent to the appropriate handler/processor, and BridgePay sends a corresponding response in real-time. BridgePay returns responses to the requesting system as a web service response message. The response includes the unique transaction identifier, request type, response code, and may include a tokenized representation of payment information, BIN response, or other data elements based on the initial request type.  
 

Overall Process

The general process cycle for a submitted service request is as follows:

  •  Web Service request received by BridgePay.

  • Superficial evaluation of request performed to determine general “properness” and to retrieve client access credentials.

  • Client access credentials used to validate client access, assign proper access rolls and to access client configuration for details on request and response formats.

  • Request message evaluated based on request format details.

  • Request processed.

  • Results of request are formatted based on response message format details.

  • Response message returned to requesting system.

 

Configuration

In order for any system to successfully communicate with the BridgePay gateway, the system (or user) must be setup for access. This includes assigning the system (or user) a user ID, a password and defining the type of access that the system (or user) will need. Multiple users at a site could share a common configuration but it is not required. Each connection profile will contain the supported access options and the appropriate response format.
 

Transaction Request Types

BridgeComm is designed to support a variety of services related to payment processing. These services are defined as request types. Depending upon the access method used, some request types may not be available. The following table lists the currently available services, the request types used to access the service and which access methods support them.

NOTE: Query String can be used for all services and transaction processing as noted in the supported categories below, with the exception of Lodging, Rental Car, Level III, and Custom Fields transaction processing (located in Request 004).

 

Service(and service code)

Request

XML

Query String

TPI  

Multi-Use Token

001

(tick)

(tick)

 

Process Payment

004

(tick)

(tick)

(tick)

Is Debit (BIN lookup)

005

(tick)

(tick)

 

Change Password

007

(tick)

 

 

Get Merchant Data

011

(tick)

(tick)

 

Void/Refund

012

(tick)

(tick)

(tick)

Tokenize Account

013

(tick)

 

 

Manage Gift Card

014

(tick)

 

 

Capture

019

(tick)

 

(tick)

Initiate Settlement

020

(tick)

 

 

Ping

099

(tick)

 

(tick)

 
SAMPLES: Working BridgeComm XML samples can be downloaded here

Quick Start Guide 

This Quick Start Guide highlights the most common request types used to easily and quickly implement to BridgeComm using Base64 encoding.

For information about TokenPay, see the TokenPay.js Implementation Guide

The highlighted requests include:

  • Multi-Use Card Token (Request 001) method is used to tokenize a single card entry without the CVV so it can be stored in a wallet.

  • Authorization/Sale (Request 004)  initiates a single transaction request and also allows for the use of the private key and payment token for capturing a card transaction. The card token and expiration date are required to preform subsequent Authorization/Sale transactions. If performing a card token request, replace<PaymentAccountNumber> with <Token> and include <ExpirationDate>.

  • Void/Refund (Request 012) issues a void against an unsettled authorization or a refund against a settled transaction. A Void request can be sent as a Refund request and the gateway will automatically process the transaction as a Void if the batch is not settled.

All requests must be Base64 encoded.

To use the samples below, replace the merchant account user, password, merchant code, and merchant account code with the test account information provided from the BridgePay Integrations department. 

Multi-Use Card Token (Request 001)

<?xml version="1.0" encoding="utf-8"?>
<requestHeader>
	<ClientIdentifier>SOAP</ClientIdentifier>
	<TransactionID>1234</TransactionID>
	<RequestType>001</RequestType>
	<RequestDateTime>20200806124522</RequestDateTime>
	<User>bpntest</User>
	<Password>57!sE@3Fm</Password>
	<requestMessage>
		<MerchantCode>575000</MerchantCode>
		<MerchantAccountCode>575004</MerchantAccountCode>
		<PaymentAccountNumber>373953244361001</PaymentAccountNumber>
		<ExpirationDate>1225</ExpirationDate>
	</requestMessage>
</requestHeader>

Multi-Use Card Token Response

<GetToken>
	<TransactionID>1234</TransactionID>
	<RequestType>001</RequestType>
	<ResponseCode>00000</ResponseCode>
	<ResponseDescription>Successful Request</ResponseDescription>
	<responseMessage>
		<Token>1000000075011001</Token>
		<ExpirationDate>1225</ExpirationDate>
		<CardBIN>414720</CardBIN>
		<OrganizationId>2380</OrganizationId>
	</responseMessage>
</GetToken>

Authorization/Sale (Request 004)

<?xml version="1.0" encoding="utf-8"?>
<requestHeader>
	<ClientIdentifier>SOAP</ClientIdentifier>
	<TransactionID>12345</TransactionID>
	<RequestType>004</RequestType>
	<RequestDateTime>20200813120822</RequestDateTime>
	<User>bpntest</User>
	<Password>57!sE@3Fm</Password>
	<requestMessage>
		<MerchantCode>575000</MerchantCode>
		<MerchantAccountCode>575004</MerchantAccountCode>
		<PaymentAccountNumber>4111111111111111</PaymentAccountNumber>
		<ExpirationDate>1222</ExpirationDate>
		<SecurityCode>999</SecurityCode>
		<Amount>4500</Amount>
		<TransactionType>sale</TranactionType>
		<TransIndustryType>EC</TransIndustryType>
		<TransCatCode>B</TransCatCode>
		<AcctType>R</AcctType>
		<InvoiceNum>1234</InvoiceNum>
		<PONum>5678</PONum>
		<SoftwareVendor>CompanyName SoftwareName Version</SoftwareVendor>
		<CustomField>997777</CustomField>
		<CustomerAccountCode>123</CustomerAccountCode>
		<AccountHolderName>CardHolder</AccountHolderName>
		<HolderType>P</HolderType>
		<AccountStreet>123 Main Street</AccountStreet>
		<AccountZip>28540</AccountZip>
	</requestMessage>
</requestHeader>

Authorization/Sale Response

<Auth>
	<TransactionID>12345</TransactionID>
	<RequestType>004</RequestType>
	<ResponseCode>00000</ResponseCode>
	<ResponseDescription>Successful Request</ResponseDescription>
	<responseMessage>
		<Token>1000000010261111</Token>
		<ExpirationDate>1222</ExpirationDate>
		<OrganizationId>2380</OrganizationId>
		<AuthorizationCode>945466</AuthorizationCode>
		<ReferenceNumber/>
		<AuthorizedAmount>4500</AuthorizedAmount>
		<OriginalAmount>4500</OriginalAmount>
		<GatewayTransID>3807822104</GatewayTransID>
		<GatewayMessage>A01 - Approved</GatewayMessage>
		<InternalMessage>Approved: 945466 (approval code)</InternalMessage>
		<GatewayResult>00000</GatewayResult>
		<AVSMessage/>
		<AVSResult/>
		<CVMessage>Matches</CVMessage>
		<CVResult>M</CVResult>
		<TransactionCode>12345</TransactionCode>
		<TransactionDate>20200813</TransactionDate>
		<RemainingAmount>0</RemainingAmount>
		<IsoCountryCode>840</IsoCountryCode>
		<IsoCurrencyCode>USD<IsoCurrencyCode>
				<IsoTransactionDate>2020-08-13 11:38:17.763</IsoTransactionDate>
				<IsoRequestDate>2020-08-13 11:38:17.763</IsoRequestDate>
				<NetworkReferenceNumber/>
				<MerchantCategoryCode/>
				<NetworkMerchantId/>
				<NetworkTerminalId/>
				<CardClass>Credit</CardClass>
				<CardType>Visa</CardType>
				<CardHolderName>CardHolder</CardHolderName>
				<CardModifier>None</CardModifier>
				<ProviderResponseCode/>
				<ProviderResponseMessage>Approved</ProviderResponseMessage>
				<MaskedPan>4***********1111</MaskedPan>
				<ResponseTypeDescription>sale</ResponseTypeDescription>
				<IsCommercialCard>False</IsCommercialCard>
				<StreetMatchMessage/>
				<WalletID/>
				<WalletPaymentMethodID/>
				<WalletResponseCode/>
				<WalletResponseMessage/>
			</responseMessage>
		</Auth>

Void/Refund Request (012)

Void from Sale example Gateway Trans ID from original sale 3807822104

<?xml version="1.0" encoding="utf-8"?>
<requestHeader>
	<ClientIdentifier>SOAP</ClientIdentifier>
	<TransactionID>12345</TransactionID>
	<RequestType>012</RequestType>
	<RequestDateTime>20200806110822</RequestDateTime>
	<User>bpntest</User>
	<Password>57!sE@3Fm</Password>
	<requestMessage>
		<MerchantCode>575000</MerchantCode>
		<MerchantAccountCode>575004</MerchantAccountCode>
		<Amount>1500</Amount>
		<ReferenceNumber>3807822104</ReferenceNumber>
		<TransactionCode>12345</TransactionCode>
		<TransactionType>refund</TransactionType>
	</requestMessage>
</requestHeader>

Void/Refund Reponse

<VoidRefund>
	<TransactionID>12345</TransactionID>
	<RequestType>012</RequestType>
	<ResponseCode>00000</ResponseCode>
	<ResponseDescription>Successful Request</ResponseDescription>
	<responseMessage/>
		<ReferenceNumber/>
		<GatewayTransID>3807822104</GatewayTransID>
		<GatewayMessage>A08 - Partial Refund Posted</GatewayMessage>
		<InternalMessage>Approved: 945466 (approval code)</InternalMessage>
		<GatewayResult>00000</GatewayResult>
		<TransactionCode>12345</TransactionCode>
		<RemainingAmount>3000</RemainingAmount>
		<OrganizationId>2380</OrganizationId>
		<MerchantAccountCode/>
		<ResponseType>refund</ResponseType>
		<ResponseTypeDescription>refund</ResponseTypeDescription>
		<CardClass/>
		<CardType/>
		<CardHolderName/>
		<CardModifier/>
		<ProviderResponseCode/>
		<ProviderResponseMessage/>
	</responseMessage>
</VoidRefund>

Response Handling and Pass-Through Data

In some cases, specific response formats are generated to meet client needs. Depending on the integration method used, different options are available for response handling.

ProcessMessage

For those integrating to BridgeComm using the ProcessMessage access method, a custom XSLT will be generated that will transform the data into the style and format you require. Only the standard response elements are available for those integration via this access method.

ProcessRequest

For those integrating to BridgeComm using the ProcessRequest access method, clients may require that the response contain specific information that was included in the proceeding request. This type of information is referred to as “pass-through data”. BridgeComm can be instructed to return pass-through data to the requesting system in every successful response. Details on how to instruct BridgeComm to return these “pass-through” data elements can be found later in this document.

 

Merchant Lookup

An important feature of the BridgePay gateway is its ability to store customer merchant account information (on behalf of customers) for transaction processing and settlement. The gateway supports storing merchant account information for each customer that uses BridgePay services.

As the gateway has no knowledge of the internal structure of any of the systems that will be utilizing gateway services, a flexible merchant account location solution has been developed. As part of initial setup and configuration, each service solution that will make use of the BridgePay gateway works with the technical team to define their merchant account lookup key (or strategy). This key can be comprised of as many components as is required to support the granularity needed by the utilizing system. The key can be comprised of existing data elements or can be extensions that only exist to facility merchant account lookup. The only requirement is that the lookup components must be supplied in each service call.

Examples

To process an authorization via the ProcessRequest access method for a merchant whose lookup strategy uses the ClientIdentifier:Gateway:MerchantKey merchant lookup pattern, the RequestMessage element would have the following tags embedded within it:

<?xml version="1.0" encoding="utf-16"?>
<requestHeader>
.
.
.
<requestMessage>
		<Gateway>XXX</Gateway>
		<MerchantKey>XXX</MerchantKey>
		<MerchantPassword>XXX</MerchantPassword>
	</requestMessage>
</requestHeader>

To process an authorization via the ProcessMessage access method for a merchant whose lookup strategy uses the ClientIdentifier:Gateway:MerchantKey merchant lookup pattern, parameters would be added to the query string:

https://url/PaymentService/Default.aspx? … &ClientIdentifier=XXX&Gateway=XXX&MerchantKey=XXX& …

For those customers you are not using specialized lookup patterns, the BridgePay merchant id and merchant account id must be provided on every message. These are provided in the MyBridgePay product at the time of boarding. All of the examples shown in this documentation will assume that the client is sending merchant lookup information using these IDs. If your implementation is customized with a different merchant lookup pattern, these parameters will not be necessary.
 

Password Management

In accordance with industry best practices, BridgePay users should change their passwords a minimum of every 90 days. BridgeComm provides service requests to support these user maintenance activities.

  • Update Password Request (007) – Updates the user’s password and resets the expiry timer.

If the user’s password is not changed before it expires, the next time that user makes a request through BridgeComm, the request will fail and return a response indicating that the password has expired (code “10023”). Until the user’s password is updated, the user will be unable to perform any other requests in the BridgePay system.

Note: Service accounts are generally set to not expire. A service account is an account that is not accessed or used by an end user to log into the system, the account is only used by a software system to facilitate transaction processing between systems.
 

Hardware Encryption

Some requests can accept hardware encrypted data. If the client uses devices that encrypt track data, that client must be specifically configured with an indicator that hardware encryption will be utilized as well as what type of decryption methods will be needed. In addition to accepting the data encrypted, there are other data elements that must be passed in with the request. These fields should be added as XML element tags in the RequestMessage element, or as query parameters in the request just as any other field would be added. For example, to process an authorization using the ProcessRequest access method for a transaction using a SecureMagV2 device, the RequestMessage element would have the following additional tags embedded within it:

<?xml version="1.0" encoding="utf-16"?>
<requestHeader>
.
.
.
	<requestMessage>
		<SecureFormat>XXX</SecureFormat>
		<BDKSlot>XXX</BDKSlot>
	</requestMessage>
</requestHeader>

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 data may be transmitted -no live payment information should ever be transmitted to the test system.

A test or live merchant account with BridgePay is necessary to successfully process transactions. To acquire a test account, complete the test account form.

You may use the following cards in testing: 

Card Type

Number

Expiry Date

Security Code

Mastercard

5439750001500347

12/29

999

Visa

4005550000000019

12/29

999

Discover

60011111111111117

12/29

999

Diners

36999999999999

12/29

999

AMEX

374255312721002

12/29

9999

 

Please use the BridgePay Integrations Support Portal to register for a new user support account from which you can request to receive a set of test cards for integrations that include swiped, card-present transactions (Credit, Debit, EBT, Gift Cards). You’ll also be able to access the Developer Support Knowledgebase, request support assistance with integration questions, as well as create, access, and track your support cases.

 

Purchase Tokens

Purchase Tokens provide a more secure way of passing authentication data to BridgePay from integrated applications such as websites that require sending username and password information as part of the request.

Conceptually, the integrating software calls a method on BridgeComm to pre-authenticate a specific transaction request. BridgeComm then records the imminent transaction, generates and returns a GUID identifying the purchase token, and begins a 15 minute count-down timer on its usage. When sending the actual transaction to BridgeComm for processing, the merchant replaces their username and password information with the previously acquired purchase token GUID. BridgeComm then compares the details of the transaction with the referenced purchase token.

If the transaction details match, the transaction is processed and the purchase token is consumed, unable to be used again. If the transaction details do not match, the transaction is declined and the purchase token is consumed, unable to be used again. If the purchase token remains unused for 15 minutes, the token is consumed, unable to be used.

For more information regarding Purchase Tokens, how to acquire one and how to consume one, see Appendix A.6 Purchase Tokens.

Implementation

Web Service Operation & Data Contracts

The request and response parameters for the ProcessRequest and ProcessMessage access methods are identical. The difference between the contracts is in the formatting of the request and response strings.

  •  ProcessRequest – Base64- encoded XML formatted request and response.

  • ProcessMessage – HTML-formatted request; custom-formatted response.

NOTE: In all tables below, “Length” refers to the maximum length of a value and this may not indicate the “standard” length.

NOTE: In all tables below, an “R” in the first column indicates a required value. Failure to supply a required value as part of a service request will result in an error. A required value in a response will always be present.
 

Base Request

The base request message requires the following parameters:

 

Parameter

Data Type

Length

Description

R

ClientIdentifier

string

50

BridgeComm requires the Idenitfier value to be set to ‘SOAP’.

Ex: <ClientIdentifier>SOAP</ClientIdentifier>

R

TransactionID

string

60

Unique value to identify the transaction. Generated by the integrating application.

R

RequestType

integer

3

Identifies the type of request message submitted. Valid values are:

  • 001 – Multi-Use Card Token Request

  • 004 – Authorization/Sale Request

  • 005 – BIN Lookup Request

  •  007 – Update Password Request

  •  011 – Get Merchant Info

  •  012 – Void/Refund

  •  014 – Manage Gift Card Request

  •  019 – Capture

  •  020 – Initiate Settlement

  •  099 – Ping

R

RequestDateTime

integer

19

The date and time the request was sent. The default format is YYYYMMDDHHMMSS using military time. This format can be overridden using the validationFormat attribute.

R

User

string

150

Provided by BridgePay. Not required when consuming a Purchase Token.

R

Password

string

225

Initially provided by BridgePay. Not required when consuming a Purchase Token.

R

requestMessage

string

n/a

XML-formatted request message string. Required for ProcessRequest only. (See Section 2.2 for details)

 

Base Response

The base response message returns the following parameters:

 

Parameter

Data Type

Length

Description

R

TransactionID

string

60

BridgeComm echoes back the TransactionID value from the request message.

R

RequestType

integer

3

BridgeComm echoes back the RequestType value from the request message. See 2.1.1 for valid values.

R

ResponseCode

integer

5

The five-digit response code describing the results of the transaction. See Appendix A.1 for valid values.

R

ResponseDescription

string

n/a

The description of the ResponseCode. See Appendix A.1 for details.

R

responseMessage

string

n/a

XML-formatted response message string. Provided by ProcessRequest only. See Section 2.2 for details.

 

Specific Request Layouts

The following sections describe the specific layouts for each request and response for each request type.

  •  When using ProcessRequest, the request data elements are embedded within a parent element called requestMessage. Response data elements are embedded within a parent element called responseMessage.

  • When using ProcessMessage, the request data elements are added as query parameters to the request string. Response data elements may be provided in the response if the XSLT is coded to return them.

 

Multi-Use Card Token (Request 001)

This request method is used to tokenize a single card entry without the CVV so that it can be stored in a wallet.
The data elements for this request type are as follows:

 

Data Element

Data Type

Length

Description

R

MerchantCode

numeric

 

Provided by MyBridgePay at the time of boarding. The element is optional based on the client's merchant lookup solution (See Section 1.6)

R

MerchantAccountCode

numeric

 

Provided by MyBridgePay at the time of boarding. The element is optional based on the client's merchant lookup solution (See Section 1.6)

1

PaymentAccountNumber

string

13-19

Credit card number. Required for keyed transactions.

1

ExpirationDate

string

7

Credit card’s expiration date Supported format are: MMYY and MM/YY. Required for keyed transactions.

O

SecureFormat

string

 

When present, indicates the format to use for decrypting the track data.

O

BDKSlot

integer

 

When present, indicates the Base Derived Key slot to use as an override for Hardware Decryption.

O

Track1

string

 

Required for swiped transactions to qualify for best rate. When present, can contain alphanumeric characters and spaces, periods, slashes (/), percent symbols (%), caret symbols (^), question marks (?), semicolons (;), equality symbols (=) or hyphens (-). Can use hardware encryption. Validated against acceptable characters in card swipe, as above. Can use hardware encryption.

O

Track2

string

 

Required for all swiped transactions. When present, can contain alphanumeric characters and spaces, periods, slashes (/), percent symbols (%), caret symbols (^), question marks (?), semicolons (;), equality symbols (=) or hyphens (-). Can use hardware encryption. Validated against acceptable characters in card swipe, as above. Can use hardware encryption.

O

Track3

string

 

Optional; used for encryption. When present, can contain alphanumeric characters and spaces, periods, slashes (/), percent symbols (%), caret symbols (^), question marks (?), semicolons (;), equality symbols (=) or hyphens (-). Can use hardware encryption. Validated against acceptable characters in card swipe, as above. Can use hardware encryption.

O

EncryptionID

string

 

The encryption ID identifying the type of encryption used on the sensitive card holder data. See 2.2.4 Generate Encryption Key Request.

O

DeviceMake

string

40

Manufacturer of terminal used. May contain any of the following characters: a-z, A-Z, 0-9, spaces, periods, dashes, or slashes (\).

O

DeviceModel

string

40

Model number of terminal used. May contain any of the following characters: a-z, A-Z, 0-9, spaces, periods, dashes or slashes (\).

O

DeviceSerial

string

40

Serial number of terminal used. May contain any of the following characters: a-z, A-Z, 0-9, spaces, periods, equal sign, hashtags, dashes or slashes (\).

O

DeviceFirmware

string

50

Firmware version number of terminal used. May contain any of the following characters: a-z, A-Z, 0-9, spaces, periods, equal sign, dashes or slashes (\).

O

RegistrationKey

string

10

Reseller / Partner registration key for PayGuardian. May contain any of the following characters: a-z, A-Z, 0-9, spaces, periods, dashes or slashes (\).

O

AppHostMachineld

string

36

GUID that identifies the HOST machine for the terminal.

O

IntegrationMethod

string

6

Identifies the PayGuardian integration method. Acceptable values are: REST, DLL, FILE, AA, SDK, VT, REST-H, DLL-H, FILE-H

O

OriginatingTechnologySource

string

N/A

Name of software transmitting the transaction.

R

SoftwareVendor

string

N/A

Name of vendor that developed the software used in transmitting the transaction. May only contain the following characters: a-z, A-Z, 0-9, spaces, and dashes.

O

SecurityTechnology

string

N/A

Security packaged used in decrypting the hardware encrypted data.

The parameters marked with a “1” are co-dependent. If one of these parameters is used, all of the co-dependent parameters must be used.

XML Request Layout

<?xml version="1.0" encoding="utf-16"?>
<requestHeader>
	<ClientIdentifier>SOAP</ClientIdentifier>
	<TransactionID>123456789</TransactionID>
	<RequestType>001</RequestType>
	<RequestDateTime>20200528120822</RequestDateTime>
	<User>bpntest</User>
	<Password>57!sE@3Fm</Password>
	<requestMessage>
		<MerchantCode>575000</MerchantCode>
		<MerchantAccountCode>575004</MerchantAccountCode>
		<PaymentAccountNumber>4111111111111111</PaymentAccountNumber>
		<ExpirationDate>1224</ExpirationDate>
		<Track1/>
		<Track2/>
		<Track3/>
		<SecureFormat/>
		<BDKSlot/>
		<EncryptionID/>
		<DeviceMake/>
		<DeviceModel/>
		<DeviceSerial/>
		<DeviceFirmware/>
		<RegistrationKey/>
		<AppHostMachineId/>
		<IntegrationMethod/>
		<OriginatingTechnologySource/>
		<SoftwareVendor>companyname softwarename version</SoftwareVendor>
		<SecurityTechnology/>
	</requestMessage>
</requestHeader>

 

Response

The response message is included in the GetToken element and returns the following data elements:

 

Data Element

Data Type

Length

Description

R

Token

integer

22

The token to be used for authorization. Note that the last four digits of the Token are the last four digits of the card number.

 

XML Response Layout

<?xml version="1.0" encoding="utf-16"?>
<GetToken>
	<TransactionID>123456789</TransactionID>
	<RequestType>001</RequestType>
	<ResponseCode>00000</ResponseCode>
	<ResponseDescription>Successful Request</ResponseDescription>
	<responseMessage>
		<Token>1000000010261111</Token>
		<ExpirationDate>1224</ExpirationDate>
		<CardBIN>414720</CardBIN>
	</responseMessage>
</GetToken>

Authorization/Sale (Request 004)

Use the authorization request to initiate a single transaction request. Please note Dynamic Descriptors, Card on File and Level III transactions are only certified on certain processors. Please reference our processor matrix to ensure functionality is certified on your processor. 

This message may require additional data required for merchant lookup. See Section 1.6 for more information.

The data elements for this request type are as follows:
   

Legend

R = Required

O = Optional

C = Conditional

1 = Required if not sending track data

3 = ACH/Checks

Required Fields

In addition to the required fields below, there are base request required fields that must be present in every transaction.

See Section 2.1.1 for a complete list of the base request required fields.

 

Data Element

Data Type

Length

Description

R

Amount

integer

8

The amount requested for authorization. Processed as implied decimal. $1.25 would be represented as 125.

R

TransactionType

string

11

Can contain letters and hyphens. Possible values: sale, sale-auth, credit, credit-auth, increment, sale-info, credit-info, adjustment

R

TransIndustryType

string

2

Must either match a 2-letter industry type for credit cards or a 3-letter SEC code for ACH transactions. All caps.

Credit Card Supported values are: RE (Retail), RS (Restaurant), EC (eCommerce), DM (Direct Marketing), LD (Lodging) and CR (Car Rental). HC is also supported for HealthCare, however internally transactions with industry type HC are converted to Retail (RE) transactions. ACH Supported values are: CCD (Corporate Credit or Debit), PPD (Prearranged Payment and Deposit Entry), POP (Point of Purchase Entry), TEL (Telephone Initiated Entry), WEB (Internet Initiated Entry), C21 (Check 21)

R

AcctType

string

1

Single character, must match pre-defined types: R (Credit Card & Branded Debit Cards), D (Unbranded Debit Cards), S (Bank Account Savings), C (Bank Account Checking), F (EBT Food Stamp), H (EBT Cash Benefit), G (Gift Card), L (Fleet), K (Check), A (Cash)

R

HolderType

string

1

Single character, either P (Personal account) or O (Organization account).

R

SoftwareVendor

string

N/A

Name of vendor that developed the software used in transmitting the transaction. May only contain the following characters: a-z, A-Z, 0-9, spaces, and dashes.

R

MerchantCode

integer

 

Provided by MyBridgePay at the time of boarding. The element is optional based on the client’s merchant lookup solution (See Section 1.7)

R

MerchantAccountCode

integer

 

Provided by MyBridgePay at the time of boarding. The element is optional based on the client’s merchant lookup solution (See Section 1.7)

Card on File Fields

*** For Future Use ***

The Card on File mandate identifies transactions processed using cardholder stored credentials.

 

Data Element

Data Type

Length

Description

O

StoredCredential

string

30

Identifies the type of card on file action taking place. Valid Values are:

  • Storing the Card/Credential for the first time:

    •  InitialUnscheduled - Indicates that a card is being stored for the first time not in association with a recurring or installment plan.

    • InitialInstallment - Indicates that a card is being stored for the first time in association with an installment plan.

    • InitialRecurring - Indicates that a card is being stored for the first time in association with a recurring plan.

  • Using the Card On File (a previously stored credential):

    • UnscheduledCustomer - Customer initiated transaction, whether in-person or on-line; that is not part of a recurring or installment plan.

    • UnscheduledMerchant - Merchant initiated transaction that is not part of a recurring or installment plan.

    • Installment - processing a payment on an installment payment plan using a card on file.

    • Recurring - processing a payment on a recurring payment plan using a card on file.

O

NetworkReferenceNumber

string

30

The "NetworkReferenceNumber" is a response field used in Recurring and Installment transactions when the "StoredCredential" element is passed with the Initial or Recurring payment request. The returned "NetworkReferenceNumber" value must also be passed in every subsequent Recurring or Installment transaction in the payment series. The updated (new) value returned from the previous (or last) transaction processed must then be submitted with the next transaction in the payment series, and so forth.  

Note: This is required for all Card Token Sales. 

Dynamic Descriptor Fields

*** For Future Use ***

A dynamic descriptor identifies the merchant’s specified information on a cardholder’s statement and can be modified on a per-transaction basis.

 

Data Element

Data Type

Length

Description

O

DynamicDescriptorText

string

38

Used to modify Dynamic Descriptor Name or Text where supported with processors

O

DynamicDescriptorAddress

string

38

Used to modify Dynamic Descriptor Address where supported with processors

O

DynamicDescriptorCity

string

21

Used to modify Dynamic Descriptor City where supported with processors

O

DynamicDescriptorCounty

string

21

Used to modify Dynamic Descriptor County where supported with processors

O

DynamicDescriptorRegion

string

21

Used to modify Dynamic Descriptor Region where supported with processors

O

DynamicDescriptorPostalCode

string

15

Used to modify Dynamic Descriptor Postal Code where supported with processors

O

DynamicDescriptorCountryCode

string

3

Used to modify Dynamic Descriptor Country Code where supported with processors

O

DynamicDescriptorEmailAddress

string

60

Used to modify Dynamic Descriptor Email Address where supported with processors

Conditional Required Fields

 

Data Element

Data Type

Length

Description

1

PaymentAccountNumber

integer

13-19

When present, must follow general Credit Card, Debit Card, EBT Card, and Gift Card conventions. Required if track or EMV data not present.

O

Token

integer

22

When present, represents the tokenized card number received from a token request. This is used in place of the PaymentAccountNumber. Note that the last four digits of the Token are the last four digits of the card number.

1

ExpirationDate

string

7

Expiration date of the card. If present, the supported format are: MMYY and MM/YY. Required if track data not present.

3

BankAccountNum

integer

 

Must contain at least one number. The bank account number for ACH and Check transactions.

3

RoutingNum

integer

10

Can contain up to 10 numbers. The routing number for ACH and Check transactions.

O

FeeAmount

integer

8

Processed as implied decimal. $1.25 would be represented as 125. Additional Fee Amount.
NOTE: Only include the FeeAmount if it is a populated value. Do not send if empty.

O

TipAmount

integer

8

Processed as implied decimal. $1.25 would be represented as 125. Additional Tip Amount. Note: Only TransIndustryType RE(Retail) and RS(Restaurant) are supported for tip adjustment. 

O

SettlementDelay

integer

1

Period for which a Sale-Auth transaction settlement is delayed. Any number between 0 – 29, noting an accepted settlement period in either ‘days’
or ‘hours’.

Wallet Processing Fields

 

Data Element

Data Type

Length

Description

O

WalletPaymentMethodID

GUID

36

This is the ID provided by the Wallet API for the payment method. When using this field, no other payment identifiers are necessary (i.e. PaymentAccountNumber, Track, BankAccountNum, etc).

O

WalletToken

string

 

A base64 encoded string describing the information the wallet information. Decoding the token will provide the Site ID, User Guid (if present), Wallet ID and Payment Method ID.

O

WalletKey

string

 

A base64 encoded string representation of the authentication key created to use the wallet token described above.

O

CustomerWalletID

string

36

The ID provided by the merchant for the payment method. When using this field, no other payment identifiers are necessary (i.e. PaymentAccountNumber, Track, BankAccountNum, etc).

Sending Track/EMV Data Fields

 

Data Element

Data Type

Length

Description

O

EncryptionID

string

 

The encryption ID identifying the type of encryption used on the sensitive card holder data. See 2.2.4 Generate Encryption Key Request.

O

SecureFormat

string

50

When present, indicates the format to use for decrypting the track data. Possible values: Bluefin, MagneSafeV1, MagneSafeV2, SecureMag and SecureMagV2.

O

BDKSlot

integer

2

When present, indicates the Base Derived Key slot to use as an override for Hardware Decryption.

O

Track1

string

 

Required for swiped transactions to qualify for best rate. When present, can contain alphanumeric characters and spaces, periods, slashes (/), percent symbols (%), caret symbols (^), question marks (?), semicolons (;), equality symbols (=) or hyphens (-). Can use hardware encryption. Validated against acceptable characters in card swipe, as above. Can use hardware encryption.

O

Track2

string

 

Required for all swiped transactions. When present, can contain alphanumeric characters and spaces, periods, slashes (/), percent symbols (%), caret symbols (^), question marks (?), semicolons (;), equality symbols (=) or hyphens (-). Can use hardware encryption. Validated against acceptable characters in card swipe, as above. Can use hardware encryption.

O

Track3

string

 

Optional; used for encryption. When present, can contain alphanumeric characters and spaces, periods, slashes (/), percent symbols (%), caret symbols (^), question marks (?), semicolons (;), equality symbols (=) or hyphens (-). Can use hardware encryption. Validated against acceptable characters in card swipe, as above. Can use hardware encryption.

O

TransactionMode

string

1

P = Card Present or N = Card Not Present.

O

DUKPT

string

20

Derived unique key per transaction used in Debit and EBT transaction encryption.

O

PINCode

string

16

Encoded PIN for Debit and EBT transactions.

O

EMVTags

string

255

Combined EMV tags presented in TLV format.

O

EntryMode

string

2

Method of entering the transaction. Possible values: MX = Manual with Signature, SX = Swipe/Scan with Signature, HX = Chip with Signature, CX = Contactless with Signature, SP = Swipe with PIN, HP = Chip with PIN

O

EntryMedium

string

2

The medium type used to initiate the transaction. Possible values: NP = Not Present, MC = Magnetic Card, CC = Chip Card, CH = Check

O

EntryPINMode

string

2

Indicates whether the input source supports PIN entry. Possible values: X = unknown, S = supported, U = Unsupported, N = Inoperative, O = Offline.

O

TerminalCapabilities

string

255

Describes the terminal’s capabilities. Can include any combination of the following tags separated by pipe characters: unknown, unused, unattended, manual, stripe, barcode, qrcode, ocr, icc, contactless, signature, rfid, micr or mobile.

O

TerminalType

string

255

Indicates the type of device/behavior when used in processing a transaction. Upper and Lower case alphanumeric charaters only. Examples: INGENICO, EDYNAMO, CHIPPER2, and WISEPAD2 (more available).

O

DeviceMake

string

40

Manufacturer of terminal used. May contain any of the following characters: a-z, A-Z, 0-9, spaces, periods, dashes, or slashes (\).

O

DeviceModel

string

40

Model number of terminal used. May contain any of the following characters: a-z, A-Z, 0-9, spaces, periods, dashes or slashes (\).

O

DeviceSerial

string

40

Serial number of terminal used. May contain any of the following characters: a-z, A-Z, 0-9, spaces, periods, equal sign, hashtags, dashes or slashes (\).

O

DeviceFirmware

string

50

Firmware version number of terminal used. May contain any of the following characters: a-z, A-Z, 0-9, spaces, periods, equal sign, dashes or slashes (\).

O

SecurityTechnology

string

N/A

Security packaged used in decrypting the hardware encrypted data.

Optional Fields

 

Data Element

Data Type

Length

Description

O

PurchaseToken

GUID

36

Provided by the AcquirePurchaseToken method. Used in place of User and Password in the base response.

O

SecurityCode

integer

3-4

When present, must be 3 or 4 digits long CVV / CVV2 of the card.

O

TransCatCode

string

1

All caps. Supported values are: B (BillPayment), R (Recurring), I (Installment), H (Healthcare).

O

VoiceAuthCode

string

15

Authorization Code for Voice Authorizations only. If authorization was achieved outside of the network (by phone or other means) you may send it through this data element to utilize the existing authorization instead of acquiring a new authorization.

O

PartialAuthorization

string

5

Must contain the literal true or the literal false. Setting this field to true indicates that a partial authorization is acceptable for this transaction. The default, if this element is not present, is false.

 

SwipeResult

future Use

 

Future use.

 

PINBlock

future Use

 

Future use.

 

PINKey

future Use

 

Future use.

O

VoucherNumber

string

15

EBT voucher clear transactions only

O

InvoiceNum

string

24

Invoice number. Spaces are not allowed. Alphanumeric and dashes accepted. User supplied data.

O

PONum

string

24

Alphanumeric and dashes accepted. User supplied data.

O

CustomerAccountCode

string

24

Alphanumeric and dashes accepted. User supplied data.

O

PaymentType

string

24

Alphanumeric, dashes and spaces accepted. User supplied data.

O

AccountHolderName

string

150

Any upper or lower case letter, hyphens, and spaces are allowed. Name on the credit card or ACH account. 

Note: This is required for the USAG/Tabapay processor. 

O

CashBackAmount

integer

8

Processed as implied decimal. $20.00 would be represented as 2000. Amount of money returned to a payment card holder. Used for Sale with cash back transactions.

O

TipRecipientCode

string

15

Can contain alphanumerics, hyphens, and periods. Server ID for the customer.

O

CustomFields

collection

n/a

Multiple based on previously configured custom fields. See <Appendix section A14> for information on transacting with custom fields. Please note the custom field elements within the CustomFields collection are case sensitive. They must be presented exactly as they were created.

O

AccountStreet

string

128

Can contain alphanumerics, spaces, hyphens, periods and slashes. Street on the account.

O

AccountZip

string

10

Postal Code on the Payment Method Account. Accepted formats are Canadian, UK and US (5 and 9 digit variation) postal codes. Alphanumeric characters ONLY (no hyphens or dashes). Alpha characters must be all upper-case.

O

AccountPhone

string

10 to 20

Billing phone number. Numerics only. No special characters allowed.

O

ContractId

integer

12

A valid BridgePay Recurring Billing System Contract Id. Provides a way to tie a transaction to a contract defined in BridgePay’s Recurring Billing System.

O

CheckImageFront

string

64000

Base64 text encoded version of the TIFF image of the front of the check being processed.

O

CheckImageBack

string

64000

Base64 text encoded version of the TIFF image of the back of the check being processed.

O

MICR

string

255

MICR data scanned by a check reader.

O

RegistrationKey

string

10

Reseller / Partner registration key for PayGuardian. May contain any of the following characters: a-z, A-Z, 0-9, spaces, periods, dashes or slashes (\).

O

AppHostMachineld

string

36

GUID that identifies the HOST machine for the terminal 

O

IntegrationMethod

string

6

Identifies the PayGuardian integration method. Acceptable values are: REST, DLL, FILE, AA, SDK, VT, REST-H, DLL-H, FILE-H

O

OriginatingTechnologySource

string

N/A

Name of software transmitting the transaction.

O

Memo

string

60

Memo for the transaction. If Memo element and the PaymentType element are provided, the Memo element will take precedence. This field may NOT contain the following characters:
“, *, &, <, >

Healthcare Fields

 

Data Element

Data Type

Length

Description

O

HealthCareAmt

integer

8

Processed as implied decimal. $1.25 would be represented as 125. The portion of the Total Amount spent on healthcare related services or products.

O

TransitAmt

integer

8

Processed as implied decimal. $1.25 would be represented as 125. The portion of the Total Amount spent on healthcare related transportation.

O

PrescriptionAmt

integer

8

Processed as implied decimal. $1.25 would be represented as 125. The portion of the Healthcare Amount spent on prescription drugs or products.

O

VisionAmt

integer

8

Processed as implied decimal. $1.25 would be represented as 125. The portion of the Healthcare Amount spent on vision related medical services.

O

DentalAmt

integer

8

Processed as implied decimal. $1.25 would be represented as 125. The portion of the Healthcare Amount spent on dental related medical services.

O

ClinicAmt

integer

8

Processed as implied decimal. $1.25 would be represented as 125. The portion of the Healthcare Amount spent on hospitalization.

O

IsQualifiedIIAS

string

 

Indicates whether purchase items are verified against IIAS as qualified for healthcare purchases. Can be lower case ‘t’ or ‘true’, or lower case ‘f’ or ‘false’.

Level II Fields

 

Data Element

Data Type

Length

Description

C

TaxRate

integer

5

Processed as implied decimal. 5.5% would be represented as 550. Additional Tax Amount. REQUIRED FOR LEVEL II/III

C

TaxAmount

integer

8

Processed as implied decimal. $1.25 would be represented as 125. REQUIRED FOR LEVEL II.

C

TaxIndicator

string

1

P (Provided), N (Not Provided), or E (Exempt). REQUIRED FOR LEVEL II/III.

C

ShipToName

string

100

Shipping address name. REQUIRED FOR LEVEL II/III.

C

ShipToStreet

string

128

Shipping address name. REQUIRED FOR LEVEL II/III.

C

ShipToCity

string

50

Shipping address name. REQUIRED FOR LEVEL II/III.

C

ShipToState

string

2

Shipping address name. REQUIRED FOR LEVEL II/III.

C

ShipToZip

string

15

Shipping address postal code. Accepted formats are Canadian, UK and US (5 and 9 digit variation) postal codes. Alpha characters must be all upper-case. REQUIRED FOR LEVEL II/III.

C

ShipToCountryCode

string

2

Shipping address country code. REQUIRED FOR LEVEL II/III. ISO 3166-1 alpha-2 codes.

Level III Fields

A B2B transaction providing specific required data fields to qualify at a lower interchange rate.

Note: All Level II fields need to be included in Level III transactions.

The Level III "Item" collection is a repeatable tag that consists of the following group of elements:
 

 

Parameter

Data Type

Length

Description

R3

ItemCode

string

12 

Unique identifier assigned to this item in the submitter’s inventory system.

R3

ItemCommodityCode

string

12

Acquirer designated standardized code that classifies this item.

R3

ItemDescription

string

35

Short description of the item.

R3

ItemQuantity

decimal

12

Quantity of item units purchased as part of this transaction. Up to 4 decimal places.

R3

ItemUnitCostAmt

integer

12

Processed as implied decimal. $1.25 would be represented as 125. Cost of a single unit of the item.

R3

ItemUnitMeasure

string

12

Unit of measure used to quantify the items purchased/refunded (e.g. kg, lb., inch).

R3

ItemTaxRate

integer

12

Processed as implied decimal. 5.5% would be represented as 550. Rate of the tax (if any) charged on this item.

R3

ItemTaxAmount

integer

8

Processed as implied decimal. $1.25 would be represented as 125. Amount of tax charged for this item.

R3

ItemTaxIndicator

string

1

P (Provided), N (Not provided), or E (Exempt).

R3

ItemTaxCode

string

4

Acquirer designated value classifying the tax that was charged for this item.

R3

ItemDiscountCode

integer

8

Processed as implied decimal. 5.5% would be represented as 550. Rate of discount (if any) that was applied to this item.

R3

ItemDiscountAmount

integer

8

Processed as implied decimal. $1.25 would be represented as 125. Total amount of discount applied to this item.

R3

ItemTotalAmount

integer

8

Processed as implied decimal. $1.25 would be represented as 125. Total amount paid for the item (including tax and discount).

R3

ItemIsCredit

string

1

True (Item is being returned), False (Default if not passed - Item is being purchased).

XML Request Layout 

<?xml version="1.0" encoding="utf-16"?>
<requestHeader>
	<ClientIdentifier>SOAP</ClientIdentifier>
	<TransactionID>123456789</TransactionID>
	<RequestType>004</RequestType>
	<RequestDateTime>20200528120822</RequestDateTime>
	<User>bpntest</User>
	<Password>57!sE@3Fm</Password>
	<requestMessage>
		<MerchantCode>575000</MerchantCode>
		<MerchantAccountCode>575004</MerchantAccountCode>
		<PurchaseToken/>
		<PaymentAccountNumber>4111111111111111</PaymentAccountNumber>
		<Token/>
		<WalletPaymentMethodID/>
		<WalletToken/>
		<WalletKey/>
		<CustomerWalletID/>
		<ExpirationDate>1224</ExpirationDate>
		<SecurityCode>999</SecurityCode>
		<Amount>700</Amount>
		<EncryptionID/>
		<SecureFormat/>
		<BDKSlot/>
		<Track1/>
		<Track2/>
		<Track3/>
		<TransactionType>sale</TransactionType>
		<TransIndustryType>RE</TransIndustryType>
		<TransactionMode/>
		<TransCatCode/>
		<Descriptor/>
		<VoiceAuthCode/>
		<PartialAuthorization/>
		<SwipeResult/>
		<PINBlock/>
		<PINKey/>
		<BankAccountNum/>
		<RoutingNum/>
		<AcctType>R</AcctType>
		<DUKPT/>
		<PINCode/>
		<VoucherNumber/>
		<InvoiceNum/>
		<PONum/>
		<CustomerAccountCode/>
		<PaymentType/>
		<AccountHolderName/>
		<HolderType>P</HolderType>
		<CashBackAmount/>
		<FeeAmount/>
		<TipAmount/>
		<TipRecipientCode/>
		<HealthCareAmt/>
		<TransitAmt/>
		<PrescriptionAmt/>
		<VisionAmt/>
		<DentalAmt/>
		<ClinicAmt/>
		<IsQualifiedIIAS/>
		<AccountStreet/>
		<AccountZip/>
		<AccountPhone/>
		<ContractId/>
		<TaxRate/>
		<TaxAmount/>
		<TaxIndicator/>
		<ShipToName/>
		<ShipToStreet/>
		<ShipToCity/>
		<ShipToState/>
		<ShipToZip/>
		<ShipToCountryCode/>
		<ShippingOriginZip/>
		<DiscountAmount/>
		<ShippingAmount/>
		<DutyAmount/>
		<TaxInvoiceCode/>
		<LocalTaxAmount/>
		<LocalTaxIndicator/>
		<NationalTaxAmount/>
		<NationalTaxIndicator/>
		<OrderCode/>
		<OrderDate/>
		<CommodityCode/>
		<CustomerAccountTaxID/>
		<CheckImageFront/>
		<CheckImageBack/>
		<MICR/>
		<EMVTags/>
		<SettlementDelay/>
		<EntryMode/>
		<EntryMedium/>
		<EntryPINMode/>
		<TerminalCapabilities/>
		<ItemCount>2</ItemCount>
		<Item>
			<ItemCode/>
			<ItemCommodityCode/>
			<ItemDescription/>
			<ItemQuantity/>
			<ItemUnitCostAmt/>
			<ItemUnitMeasure/>
			<ItemTaxAmount/>
			<ItemTaxRate/>
			<ItemTaxIndicator/>
			<ItemTaxCode/>
			<ItemDiscountRate/>
			<ItemTotalAmount/>
			<ItemIsCredit/>
		</Item>
		<Item>
			<ItemCode/>
			<ItemCommodityCode/>
			<ItemDescription/>
			<ItemQuantity/>
			<ItemUnitCostAmt/>
			<ItemUnitMeasure/>
			<ItemTaxAmount/>
			<ItemTaxRate/>
			<ItemTaxIndicator/>
			<ItemTaxCode/>
			<ItemDiscountRate/>
			<ItemTotalAmount/>
			<ItemIsCredit/>
		</Item>
		<CustomFields>
			<CustomField1/>
		</CustomFields>
		<DeviceMake/>
		<DeviceModel/>
		<DeviceSerial/>
		<DeviceFirmware/>
		<RegistrationKey/>
		<AppHostMachineId/>
		<IntegrationMethod/>
		<OriginatingTechnologySource/>
		<SoftwareVendor/>
		<SecurityTechnology/>
	</requestMessage>
</requestHeader>


Response 

The response message is included in the Auth element and returns the following data elements:

 

Data Element

Data Type

Length

Description

 

Token

string

22

Either the token submitted with the original authorization request or a tokenized version of the submitted payment account number if no token was provided in the request. Note that the last four digits of the Token are the last four digits of the card number.

 

MerchantAccountCode

integer

 

Provided by MyBridgePay at the time of boarding. The element is optional based on the client’s merchant lookup solution.

 

AuthorizationCode

string

50

The transaction authorization code returned from the processor.

 

ReferenceNumber

string

 

For future use.

 

GatewayResult

string

 

Echo of the ResponseCode.

 

AuthorizedAmount

integer

8

Implied decimal, amount of the charge that was authorized.

 

OriginalAmount

integer

8

Implied decimal, amount that was requested for authorization.

 

ExpirationDate

string

6

Echo back of the expiration date.

 

AVSResult

string

 

Unipay AVS Match Result Code.

 

AVSMessage

string

 

Unipay AVS Match Result Message.

 

StreetMatchMessage

string

 

For future use.

 

ZipMatchMessage

string

 

For future use.

 

CVResult

string

 

Unipay CVV/CVV2 Match Result Code.

 

CVMessage

string

 

Unipay CVV/CVV2 Match Result Message.

 

IsCommercialCard

Boolean

 

For future use.

 

GatewayTransID

integer

 

Transaction ID from the gateway (used as Reference Number for Voids / Refunds).

 

GatewayMessage

string

 

Message from the gateway.

 

InternalMessage

string

 

Provides more information from the gateway and processor regarding the results of the transaction request.

 

Balance

integer

 

For future use.

 

CashBackAmount

integer

8

For future use.

 

TransactionCode

string

 

Echo back of the TransactionCode.

 

TransactionDate

string

 

Echo back of the TransactionDate.

 

CardClass

string

25

Displays the tender type used to process a transaction. List of values: Credit, Debit, Gift, Prepaid, EBT, Fleet, None

 

CardType

string

25

Displays the card type (determined by BIN range). List of values: Visa, Mastercard, Discover, Amex, Diners, JCB, CUP (China Union Pay), Bank, None.

 

CardModifier

string

25

Displays the featured function submitted in addition to the tender type used to process a transaction. List of values: FSA, Commercial, FoodStamp, CashBenefit, Cash, None.

 

CardHolderName

string

200

Displays the cardholder name as provided in the request message, or from the device.

 

ProviderResponseCode

string

25

Displays the response code as provided by the Processor.

 

ProviderResponseMessage

string

255

Displays the response message as provided by the Processor.

 

RemainingAmount

integer

8

Any amount of the original authorization remaining after this void / refund. This amount is in implied decimal format (i.e. $19.95 = 1995).

 

IsoCountryCode

string

 

 

 

IsoCurrencyCode

string

 

 

 

IsoTransactionDate

string

 

 

 

IsoRequestDate

string

 

 

 

NetworkReferenceNumber

string

 

 

 

NetworkMerchantId

string

20

 

 

NetworkTerminalId

string

20

 

 

MaskedPan

string

 

 

 

WalletID

string

 

 

 

WalletPaymentMethodID

string

 

 

 

WalletResponseMessage

string

 

 

 

WalletResponseCode

string

 

 

 

ResponseTypeDescription

string

 

 

 

MerchantCategoryCode

string

 

Returned tag data for generating the receipt.

*

ReceiptTagData

string

 

Returned tag data from the issuer.

*

IssuerTagData

string

 

Returned tag data from the issuer.

* ReceiptTagData and IssuerTagData are only returned when the authorization is processed as an EMV transaction.
 

 

XML Response Layout

<?xml version="1.0" encoding="utf-16"?>
<Auth>
	<TransactionID>123456789</TransactionID>
	<RequestType>004</RequestType>
	<ResponseCode>00000</ResponseCode>
	<ResponseDescription>Successful Request</ResponseDescription>
	<responseMessage>
		<Token>1000000010261111</Token>
		<MerchantAccountCode>575000</MerchantAccountCode>
		<AuthorizationCode>642973</AuthorizationCode>
		<ReferenceNumber/>
		<GatwayResult>00000</GatewayResult>
		<AuthorizedAmount>700</AuthorizedAmount>
		<OriginalAmount>700</OriginalAmount>
		<ExpirationDate>1224</ExpirationDate>
		<AVSMessage>Street address and ZIP match</AVSMessage>
		<AVSResult>4F</AVSResult>
		<StreetMatchMessage/>
		<ZipMatchMessage/>
		<CVMessage>Matches</CVMessage>
		<CVResult>M</CVResult>
		<IsCommercialCard>False</IsCommercialCard>
		<GatewayTransID>1235539604</GatewayTransID>
		<GatewayMessage>A01 - Approved</GatewayMessage>
		<InternalMessage>Approved: 642973 (approval Code)</InternalMessage>
		<Balance/>
		<CashBackAmount/>
		<TransactionCode>123456789</TransactionCode>
		<TransactionDate>20200528</TransactionDate>
		<RemainingAmount>0</RemainingAmount>
		<IsoCountryCode>840</IsoCountryCode>
		<IsoCurrencyCode>USD</IsoCurrencyCode>
		<IsoTransactionDate>2020-05-28 12:41:33.587</IsoTransactionDate>
		<IsoRequestDate>2020-05-28 12:41:33.587</IsoRequestDate>
		<NetworkReferenceNumber/>
		<NetworkMerchantId/>
		<NetworkTerminalId/>
		<CardClass>Credit</CardClass>
		<CardType>Visa</CardType>
		<CardHolderName>Test card</CardHolderName>
		<CardModifier>None</CardModifier>
		<ProviderResponseCode/>
		<ProviderResponseMessage>Approved</ProviderResponseMessage>
		<MaskedPan/>
		<WalletID/>
		<WalletPaymentMethodID/>
		<WalletResponseMessage/>
		<WalletResponseCode/>
		<MerchantCategoryCode/>
		<ResponseTypeDescription>sale</ResponseTypeDescription>
		<ReceiptTagData/>
		<IssuerTagData/>
	</responseMessage>
</Auth>

BIN Lookup (Request 005)

Use the BIN lookup request to determine if the BIN is a Debit Card. By default, if the BIN is not defined as Debit, a defined value of Credit will be returned.

The data elements for this request type are as follows:

 

Data Element

Data Type

Length

Description

R

BIN

integer

11

The 8 to 11-digit BIN number to be looked up. As this is only a BIN number, it need not be encrypted and does not support being encrypted.

XML Request Layout

<?xml version="1.0" encoding="utf-16"?>
<requestHeader>
	<ClientIdentifier/>
	<TransactionID/>
	<RequestType>005</RequestType>
	<RequestDateTime/>
	<User/>
	<Password/>
	<requestMessage>
		<BIN/>
	</requestMessage>
</requestHeader> 

Response

The response message is included in the BINLookup element and returns the following data elements:

 

Data Element

Data Type

Length

Description

R

CardIdentifier

string

 

The card type for the submitted BIN.

Response Layout

<?xml version="1.0" encoding="utf-16"?>
<BINLookup>
	<TransactionID/>
	<RequestType>005</RequestType>
	<ResponseCode>00000</ResponseCode>
	<responseMessage>
		<CardIdentifier/>
	</responseMessage>
</BINLookup> 



Change Password (Request 007)

Use the change password request to update the user’s password.

Passwords must contain a minimum of 6 characters, with at least one upper case letter, one lower case letter, and one numeric character.

The data elements for this request type are as follows:

 

Data Element

Data Type

Length

Description  

R

NewPassword

string

 

The new password for the user.

R

ConfirmPassword

string

 

The re-entered new password for the user, to confirm the new value.

Request Layout

<?xml version="1.0" encoding="utf-16"?>
<requestHeader>
	<ClientIdentifier/>
	<TransactionID/>
	<RequestType>007</RequestType>
	<RequestDateTime/>
	<User/>
	<Password/>
	<requestMessage>
		<NewPassword/>
		<ConfirmPassword/>
	</requestMessage>
</requestHeader> 

Response

The response message is included in the UpdatePassword with no extra data elements.

XML Response Layout

<?xml version="1.0" encoding="utf-16"?>
<UpdatePassword>
	<TransactionID/>
	<RequestType>007</RequestType>
	<ResponseCode>00000</ResponseCode>
</UpdatePassword> 



Get Merchant Info (Request 011)

Use the merchant info request to retrieve the default merchant information for your credentials.

The Get Merchant Info request can use the PurchaseToken without consuming the purchase token. Simply provide the PurchaseToken along with the request, excluding the User and Password fields, to retrieve the merchant information.

The data elements for this request type are as follows:

 

Data Element

Data Type

Length

Description

O

Purchase Token

GUID

36

Provided by the AcquirePurchaseToken method. Used in place of User and Password in the base response.

Request Layout 

<?xml version="1.0" encoding="utf-16"?>
<requestHeader>
	<ClientIdentifier/>
	<TransactionID/>
	<RequestType>011</RequestType>
	<RequestDateTime/>
	<User/>
	<Password/>
	<requestMessage>
		<PurchaseToken/>
	</requestMessage>
</requestHeader> 

Response

The response message is included in the GetMerchantInfo element and returns the following data elements:

 

Data Element

Data Type

Length

Description

R

MerchantCode

integer

12

The default merchant code assigned to the user.

R

MerchantAccountCode

integer

12

The default merchant account code assigned to the user.

R

MerchantName

string

50

The name assigned to the merchant account.

R

GatewayResults

string

5

Results from the Gateway (5 digit code).

R

GatewayTransID

integer

12

Transaction ID for the request.

R

GatewayMessage

string

255

Message from the Gateway regarding this request.

XML Response Layout

<?xml version="1.0" encoding="utf-16"?>
<GetMerchantInfo>
	<TransactionID/>
	<RequestType>0011</RequestType>
	<ResponseCode>00000</ResponseCode>
	<responseMessage>
		<MerchantCode/>
		<MerchantAccountCode/>
		<MerchantName/>
		<GatewayResults/>
		<GatewayTransID/>
		<GatewayMessage/>
	</responseMessage>
</GetMerchantInfo>

 


Void/Refund (Request 012)

Use the void/refund request to issue a void against an unsettled authorization or a refund against a settled transaction. 

  This message may require additional data required for merchant lookup. See section 1.6 for more information.

The Void/Refund request can use a previously used PurchaseToken for one void/refund operation only. Simply provide the PurchaseToken along with the request, excluding the User and Password fields, to retrieve the merchant information.

The data elements for this request type are as follows:

 

Data Element

Data Type

Length

Description 

R

MerchantCode

integer

 

Provided by MyBridgePay at the time of boarding. The element is necessary unless the client is using a different merchant lookup solution (See Section 1.6)

R

MerchantAccountCode

integer

 

Provided by MyBridgePay at the time of boarding. The element is necessary unless the client is using a different merchant lookup solution (See Section 1.6)

R

Amount

integer

8

Processed as implied decimal. $1.25 would be represented as 125. The amount requested to be refunded / voided.

R

ReferenceNumber

integer

12

The GatewayTransId returned as a part of the response to request 004.

R

TransactionType

string

6

Can contain letters and hyphens. Must match a one of the defined transaction types in Unipay. Should use “void” or “refund” only for this request type.

R

TransactionCode

string

 

Must match the TransactionID in the requestHeader

O

PurchaseToken

GUID

36

Provided by the AcquirePurchaseToken method. Must be the same Purchase Token acquired and used for an authorization or sale. Used in place of User and Password in the base response.

O

OriginatingTechnologySource

string

N/A

Name of software transmitting the transaction.

R

SoftwareVendor

string

N/A

Name of vendor that developed the software used in transmitting the transaction. May only contain the following characters: a-z, A-Z, 0-9, spaces, and dashes.

O

SecurityTechnology

string

N/A

Security packaged used in decrypting the hardware encrypted data.

O

CustomerAccountCode

string

24

Alphanumeric and dashes accepted. User supplied data.

O

InvoiceNum

string

24

Invoice number. Spaces are not allowed. Alphanumeric and dashes accepted. User supplied data.

O

DeviceMake

string

40

Manufacturer of terminal used. May contain any of the following characters: a-z, A-Z, 0-9, spaces, periods, dashes, or slashes (\).

O

DeviceModel

string

40

Model number of terminal used. May contain any of the following characters: a-z, A-Z, 0-9, spaces, periods, dashes or slashes (\).

O

DeviceSerial

string

40

Serial number of terminal used. May contain any of the following characters: a-z, A-Z, 0-9, spaces, periods, equal sign, hashtags, dashes or slashes (\).

O

DeviceFirmware

string

50

Firmware version number of terminal used. May contain any of the following characters: a-z, A-Z, 0-9, spaces, periods, equal sign, dashes or slashes (\).

O

RegistrationKey

string

10

Reseller / Partner registration key for PayGuardian. May contain any of the following characters: a-z, A-Z, 0-9, spaces, periods, dashes or slashes (\).

O

AppHostMachineId

string

36

GUID that identifies the HOST machine for the terminal.

O

IntegrationMethod

string

6

Identifies the PayGuardian integration method. Acceptable values are: REST, DLL, FILE, AA, SDK, VT, REST-H, DLL-H, FILE-H

O

EMVTags

string

255

Combined EMV tags presented in TLV format.

O

VoidReasonCode

string

20

Idenitifies the reason a transaction was voided from a device. Acceptable values are: CustomerInitiated, TimeoutReversal, System Malfunction, SuspectedFraud, PrematureCardRemoval, ChipDecline.

O

Memo

string

60

Memo for the transaction. This field may NOT contain the following characters:
“, *, &, <, >.

 

XML Request Layout 

<?xml version="1.0" encoding="utf-16"?>
<requestHeader>
	<ClientIdentifier/>
	<TransactionID/>
	<RequestType>012</RequestType>
	<RequestDateTime/>
	<User/>
	<Password/>
	<requestMessage>
		<MerchantCode/>
		<MerchantAccountCode/>
		<Amount/>
		<ReferenceNumber/>
		<TransactionType/>
		<TransactionCode/>
		<PurchaseToken/>
		<OriginatingTechnologySource/>
		<SoftwareVendor/>
		<SecurityTechnology/>
		<CustomerAccountCode/>
		<InvoiceNum/>
		<DeviceMake/>
		<DeviceModel/>
		<DeviceSerial/>
		<DeviceFirmware/>
		<RegistrationKey/>
		<AppHostMachineId/>
		<IntegrationMethod/>
		<EMVTags/>
		<VoidReasonCode/>
	</requestMessage>
</requestHeader>

Response

The response message is included in the VoidRefund element and returns the following data elements:

 

Data Element

Data Type

Length

Description 

R

ReferenceNumber

 

 

The reference number of the refund or of the original authorization if this was a void.

R

TransactionCode

 

 

The TransactionCode that was send with the request.

R

RemainingAmount

Integer

8

Any amount of the original authorization remaining after this void / refund. This amount is in implied decimal format (i.e. $19.95 = 1995).

R

ResponseType

string

 

Action that was performed: “Void” or “refund”.

R

MerchantAccountCode

 

 

The merchant account code used to process the original authorization and the void or refund.

 

CardType

string

25

Displays the card type (determined by BIN range). List of values: Visa, Mastercard, Discover, Amex, Diners, JCB, CUP (China Union Pay), Bank, None.

 

CustomFields

string

25

If the Sale that is being refunded had custom fields they will be returned in the response.  See Section A.13 for
more information on custom fields.

XML Response Layout

<?xml version="1.0" encoding="utf-16"?>
<requestHeader>
	<ClientIdentifier/>
	<TransactionID/>
	<RequestType>013</RequestType>
	<RequestDateTime/>
	<User/>
	<Password/>
	<requestMessage>
		<MerchantCode/>
		<MerchantAccountCode/>
		<BankAccountNum/>
		<OriginatingTechnologySource/>
		<SoftwareVendor/>
		<SoftwareTechnology/>
		<DeviceMake/>
		<DeviceModel/>
		<DeviceSerial/>
		<DeviceFirmware/>
		<RegistrationKey/>
		<AppHostMachineId/>
		<IntegrationMethod/>
	</requestMessage>
</requestHeader> 



Tokenize Account (Request 013)

Use the Tokenize Account request to tokenize a bank account number for ACH transactions.

The data elements for this request type are as follows:
 

 

Data Element

Data Type

Length

Description

R

BankAccountNum

integer

 

Must contain at least one number. The bank account number for ACH transactions.

O

OriginatingTechnologySource

string

N/A

Name of software transmitting the transaction.

R

SoftwareVendor

string

N/A

Name of vendor that developed the software used in transmitting the transaction. May only contain the following characters: a-z, A-Z, 0-9, spaces, and dashes.

O

SecurityTechnology

string

N/A

Security packaged used in decrypting the hardware encrypted data.

O

DeviceMake

string

40

Manufacturer of terminal used. May contain any of the following characters: a-z, A-Z, 0-9, spaces, periods, dashes, or slashes (\).

O

DeviceModel

string

40

Model number of terminal used. May contain any of the following characters: a-z, A-Z, 0-9, spaces, periods, dashes or slashes (\).

O

DeviceSerial

string

40

Serial number of terminal used. May contain any of the following characters: a-z, A-Z, 0-9, spaces, periods, equal sign, hashtags, dashes or slashes (\).

O

DeviceFirmware

string

50

Firmware version number of terminal used. May contain any of the following characters: a-z, A-Z, 0-9, spaces, periods, equal sign, dashes or slashes (\).

O

RegistrationKey

string

10

Reseller / Partner registration key for PayGuardian. May contain any of the following characters: a-z, A-Z, 0-9, spaces, periods, dashes or slashes (\).

O

AppHostMachineId

string

36

GUID that identifies the HOST machine for the terminal.

O

IntegrationMethod

string

6

Identifies the PayGuardian integration method. Acceptable values are: REST, DLL, FILE, AA, SDK, VT, REST-H, DLL-H, FILE-H

XML Request Layout

<?xml version="1.0" encoding="utf-16"?>
<requestHeader>
	<ClientIdentifier/>
	<TransactionID/>
	<RequestType>013</RequestType>
	<RequestDateTime/>
	<User/>
	<Password/>
	<requestMessage>
		<MerchantCode/>
		<MerchantAccountCode/>
		<BankAccountNum/>
		<OriginatingTechnologySource/>
		<SoftwareVendor/>
		<SoftwareTechnology/>
		<DeviceMake/>
		<DeviceModel/>
		<DeviceSerial/>
		<DeviceFirmware/>
		<RegistrationKey/>
		<AppHostMachineId/>
		<IntegrationMethod/>
	</requestMessage>
</requestHeader> 

Response

The response message is included in the GetToken element and returns the following data elements:

 

Data Element

Data Type

Length

Description

R

Token

integer

22

The 22-digit token to be used for authorization.

XML Response Layout

<?xml version="1.0" encoding="utf-16"?>
<GetToken>
<TransactionID></TransactionID>
<RequestType>013</RequestType>
<ResponseCode>00000</ResponseCode>
<responseMessage>
<Token></Token>
<CardBIN>414720 </CardBIN>
</responseMessage>
</GetToken> 

 


Account Verification and Balance Inquiry (Request 015)

Use the Account Inquiry request to obtain information from BridgeComm for a given credit card to return valid card, correct CVV and/or correct zip code. This function returns information like a sale process except it does not charge the card. See Appendix A.1 for response code values. 

When providing a CVV with the 015 Account Verification request to the Proxy server, and likely other test processors, the value must match the values outlined in the certification script. If another CVV value is provided, the transaction will fail with a message indicating the card information did not match. The are summarized below:

  • AMEX = 1234 or 1111

  • Visa/MasterCard/Discover = 999 or 111

Request 015 may be used with the AuthenticationTokenId's provided by TokenPay; however, the Username, Password, MerchantCode, and MerchantAccountCode will be replaced with an AuthenticationTokenId and PrivateKey. Below is a sample request and response:

NOTE: Balance Inquiry is only included for gift cards and EBT. EBT samples shown below.

Request

The data elements for this request type are as follows:

 

Data Element

Data Type

Length

Description

R

User

String

150

User name assigned to the merchant account.

R

Password

String

255

Password assigned to the merchant account. 

R

MerchantCode

numeric

 

The default merchant code assigned to the merchant account.

R

MerchantAccountCode

numeric

 

The default merchant account code assigned to the merchant account. 

R

RequestDateTime

numeric

19

The date and time the request was sent. The default format is YYYYMMDDHHMMSS using military time.

R

TransactionID

String

60

Unique transaction ID sent in with the request.

R

TransactionType

enum

20

Identifies the action to take. Can be balance-inquiry or account-verification.

NOTE: At this time only balance-inquiry is only supported for gift cards and EBT. 

R

PaymentAccountNumber

integer

13-19

Full credit card number

R

ExpirationDate

string

7

Expiration date of the card. If present, the supported format are: MMYY and MMYY

R

AcctType

string

1

Single character, must be set to R

R

TransIndustryType

string

2

Must match a predetermined 2-letter industry type. All caps. Supported values are: RE (Retail), RS (Restaurant), EC (eCommerce), DM (Direct Marketing), LD (Lodging) and CR (Car Rental). HC is also supported for HealthCare, however internally transactions with industry type HC are converted to Retail (RE) transactions.

O

SecurityCode

numeric

3-4

When present, must be 3 or 4 digits long CVV/CVV2 of the card.

O

AccountStreet

string

128

Street of the billing address. Can contain alphanumerics, spaces, hyphens, periods and slashes. Street on the account

O

AccountZip

string

10

Postal Code of the billing address. Accepted formats are Canadian, UK and US (5 and 9 digit variation) postal codes. Alphanumeric characters ONLY (no hyphens or dashes). Alpha characters must be all upper-case.

O

AccountHolderName

string

 

Name on the credit card or ACH account. 

 

Request Layout 

<requestHeader>
	<ClientIdentifier>SOAP</ClientIdentifier>
	<TransactionID>exAccountVerification1657031359</TransactionID>
	<RequestType>015</RequestType>
	<PrivateKey>TtXNMYZUXRSZ1234</PrivateKey>
	<AuthenticationTokenId>b6de4a18-1234-4ede-9a52-c7e60156444f</AuthenticationTokenId>
	<requestMessage>
		<TransIndustryType>RE</TransIndustryType>
		<TransactionType>account-verification</TransactionType>
		<AccountZip>33774</AccountZip>
		<AcctType>R</AcctType>
	</requestMessage>
</requestHeader>

XML Request Layout

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<requestHeader>
	<ClientIdentifier>SOAP</ClientIdentifier>
	<TransactionID/>
	<RequestType>015</RequestType>
	<RequestDateTime/>
	<User/>
	<Password/>
	<requestMessage>
		<MerchantCode/>
		<MerchantAccountCode/>
		<TransactionType/>
		<PaymentAccountNumber/>
		<AcctType/>
		<AccountHolderName/>
		<ExpirationDate/>
		<SecurityCode/>
		<AccountStreet/>
		<AccountZip/>
		<TransIndustryType/>
	</requestMessage>
</requestHeader> 

Response

The response message is included in the AccountInquiry element and returns the following data elements:

 

Data Element

Data Type

Length

Description

 

TransactionID

String

 

Unique transaction ID sent in with the request.

 

TransactionType

enum

10

Identifies the administrative action taken. Can be BalanceInquiry or Account-Verification.

NOTE: In this release, it can only be BalanceInquiry

 

ResponseCode

numeric

5

The numeric value of the response identified in appendix A.1. 

 

ResponseDescription 

string

 

The description of the error response code.

 

ResponseType

enum

9

Identifies the type of response received. Can be Good, Soft, Hard or Exception.

 

Token

string

22

A tokenized version of the submitted payment account number. Note that the last four digits of the Token are the last four digits of the card number.

 

ExpirationDate

string

6

Echo back of the expiration date.

 

ReferenceNumber

integer

 

Identifies the BridgePay Gateway ID number of the request.

 

GatewayResult

string

3

The BridgePay Gateway’s internal code for the result of the request.

 

GatewayMessage

string

 

The BridgePay Gateway’s internal message corresponding to the GatewayResult field.

 

TransactionDate

DateTime

14

Date of the request. Format: yyyyMMddHHmmss

 

Balance

integer

8

Amount of money remaining on the card. Provided as implied decimal. $1.25 would be represented as 125.

 

AuthrorizationCode

string

50

The transaction authorization code returned from the processor.

 

AVSResult

string

2

The BridgePay Gateway AVS Result Code.

 

AVSMessage

string

255

The message associated with the AVSResult field

 

CVResult

string

1

The BridgePay Gateway CVV Result Code.

 

CVMessage

string

255

The message associated with the CVResult field.

 

ProviderAVSCode

string

5

Original provider’s AVS Response Code

 

ProviderCVCode

string

1

Original provider’s CVV Response Code

 

ProviderReferenceNumber

string

50

Reference number of the underlying provider.

 

OrganizationId

numeric

4

Identifier of the organization. 

 

NetworkMerchantId

string

20

The Network Merchant Id

 

NetworkTerminalId

string

20

The Network Terminal Id 

  Response Layout

<AccountInquiry>
	<TransactionID>exManual1657031359</TransactionID>
	<RequestType>015</RequestType>
	<ResponseCode>00000</ResponseCode>
	<ResponseDescription>Successful Request</ResponseDescription>
	<responseMessage>
		<ReferenceNumber>4175409304</ReferenceNumber>
		<GatewayResult>00000</GatewayResult>
		<GatewayMessage>A01 - Approved</GatewayMessage>
		<TransactionType>AccountVerification</TransactionType>
		<ResponseType>Good</ResponseType>
		<Token>100000044935454<Token>
				<ExpirationDate>0527</ExpirationDate>
				<TransactionDate>20220705</TransactionDate>
				<Balance/>
				<AuthrorizationCode/>
				<AVSResult/>
				<AVSMessage/>
				<CVResult>M</CVResult>
				<CVMessage>Matches</CVMessage>
				<ProviderAVSCode/>
				<ProviderCVCode/>
				<ProviderReferenceNumber/>
				<NetworkMerchantId>12180001</NetworkMerchantId>
				<NetworkTerminalId>10001</NetworkTerminalId>
				<OrganizationId>2647</OrganizationId>
			</responseMessage>
		</AccountInquiry> 

 

XML Response Layout

<AccountInquiry>
	<TransactionID/>
	<RequestType>015</RequestType>
	<ResponseCode/>
	<ResponseDescription/>
	<responseMessage>
		<ReferenceNumber/>
		<GatewayResult/>
		<GatewayMessage/>
		<TransactionType/>
		<ResponseType/>
		<Token>
			<Token>
				<ExpirationDate/>
				<TransactionDate/>
				<Balance/>
				<AuthrorizationCode/>
				<AVSResult/>
				<AVSMessage/>
				<CVResult/>
				<CVMessage/>
				<ProviderAVSCode/>
				<ProviderCVCode/>
				<ProviderReferenceNumber/>
				<OrganizationId/>
				<NetworkMerchantId/>
				<NetworkTerminalId/>
			</responseMessage>
		</AccountInquiry> 

EBT Food Stamp Balance Sample

<requestHeader>
	<ClientIdentifier>SOAP</ClientIdentifier>
	<RequestType>015</RequestType>
	<TransactionID>CC_TC_18</TransactionID>
	<RequestDateTime>2018-11-27T09:00:00</RequestDateTime>
	<User>Username</User>
	<Password>Password1</Password>
	<requestMessage>
		<CurrencyCode>USD</CurrencyCode>
		<MerchantCode>2000</MerchantCode>
		<MerchantAccountCode>2126</MerchantAccountCode>
		<TransIndustryType>RE</TransIndustryType>
		<PartialAuthorization>true</PartialAuthorization>
		<Track2>;4012000098765439=20121011796251900000?<Track2>
				<DUKPT>000000008F000021</DUKPT>
				<PINCode>623F36B53CC18393</PINCode>
				<TerminalCapabilities>manual|stripe|icc|signature|rfid|contactless</TerminalCapabilities>
				<Amount>0</Amount>
				<TransactionType>balanceinquiry</TransactionType>
				<HolderType>P</HolderType>
				<AcctType>F</AcctType>
			</requestMessage>
		</requestHeader> 

EBT Cash Benefits Balance Sample

<requestHeader>
	<ClientIdentifier>SOAP</ClientIdentifier>
	<RequestType>015</RequestType>
	<TransactionID>CC_TC_18</TransactionID>
	<RequestDateTime>2018-11-27T09:00:00</RequestDateTime>
	<User>Username</User>
	<Password>Password1</Password>
	<requestMessage>
		<CurrencyCode>USD</CurrencyCode>
		<MerchantCode>2000</MerchantCode>
		<MerchantAccountCode>2126</MerchantAccountCode>
		<TransIndustryType>RE</TransIndustryType>
		<PartialAuthorization>true</PartialAuthorization>
		<Track2>;4012000098765439=20121011796251900000?<Track2>
				<DUKPT>000000008F000021</DUKPT>
				<PINCode>623F36B53CC18393</PINCode>
				<TerminalCapabilities>manual|stripe|icc|signature|rfid|contactless</TerminalCapabilities>
				<Amount>0</Amount>
				<TransactionType>balanceinquiry</TransactionType>
				<HolderType>P</HolderType>
				<AcctType>H</AcctType>
			</requestMessage>
		</requestHeader>


Capture (Request 019)

This request method is used to confirm a previously authorized sale. This is used for merchants that are not setup to AutoConfirm their transactions. Transactions that are not confirmed will be voided at settlement time.

   This message may require additional data required for merchant lookup. See section 1.6 for more information. This               message may also require additional data for lodging check-out transactions.

The data elements for this request type are as follows:

 

Parameter

Data Type

Length

Description 

R

MerchantCode

integer

 

Provided by MyBridgePay at the time of boarding. The element is necessary unless the client is using a different merchant lookup solution (See Section 1.6)

R

MerchantAccountCode

integer

 

Provided by MyBridgePay at the time of boarding. The element is necessary unless the client is using a different merchant lookup solution (See Section 1.6)

R

Amount

integer

8

Processed as implied decimal. $1.25 would be represented as 125. The amount to be confirmed. For new authorizations, can be 100% or less of the original auth amount. For previously confirmed transactions, can be 100% of the previously confirmed amount. For lodging transactions, can be greater or less than the total authorized for the lodging key.

C

ReferenceNumber

integer

 

The GatewayTransId returned as part of the auth response (004). Conditionally Required – Not required for Lodging Transactions

R

TransactionType

string

 

Can contain letters and hyphens. Must match a one of the defined transaction types in Unipay. Should use “capture” only for this request type.

R

TransactionCode

string

 

Must match the TransactionID in the requestHeader

C

FolioNumber

string

15

Hotel folio number. Required when capturing a lodging transaction.

C

CheckInDate

Date

 

The date of actual or anticipated check-in. Required when capturing a lodging transaction.

C

Token

integer

22

When present, represents the tokenized card number received from a token request or authorization. Required when capturing a lodging transaction. Note that the last four digits of the Token are the last four digits of the card number.

O

SettlementDelay

integer

1

Designates the number of batch cycles that a Sale-Auth transaction remains open (unsettled). If the Sale-Auth is not captured before completion of the set number of batch cycles passed into the Settlement Delay field of the original transaction, the Sale-Auth transaction will auto-void.

Note: Minimum and Maximum range period to delay the auto-void of a Sale-Auth is between 0 – 30 (0 = current batch period, 30 = 30 batch periods).

O

OriginatingTechnologySource

string

N/A

Name of software transmitting the transaction.

R

SoftwareVendor

string

N/A

Name of vendor that developed the software used in transmitting the transaction. May only contain the following characters: a-z, A-Z, 0-9, spaces, and dashes.

O

SecurityTechnology

string

N/A

Security packaged used in decrypting the hardware encrypted data.

O

DeviceMake

string

40

Manufacturer of terminal used. May contain any of the following characters: a-z, A-Z, 0-9, spaces, periods, dashes, or slashes (\).

O

DeviceModel

string

40

Model number of terminal used. May contain any of the following characters: a-z, A-Z, 0-9, spaces, periods, dashes or slashes (\).

O

DeviceSerial

string

40

Serial number of terminal used. May contain any of the following characters: a-z, A-Z, 0-9, spaces, periods, equal sign, hashtags, dashes or slashes (\).

O

DeviceFirmware

string

50

Firmware version number of terminal used. May contain any of the following characters: a-z, A-Z, 0-9, spaces, periods, equal sign, dashes or slashes (\).

O

RegistrationKey

string

10

Reseller / Partner registration key for PayGuardian. May contain any of the following characters: a-z, A-Z, 0-9, spaces, periods, dashes or slashes (\).

O

AppHostMachineId

string

36

GUID that identifies the HOST machine for the terminal.

O

IntegrationMethod

string

6

Identifies the PayGuardian integration method. Acceptable values are: REST, DLL, FILE, AA, SDK, VT, REST-H, DLL-H, FILE-H

O

Memo

string

60

Memo for the transaction. This field may NOT contain the following characters:
“, *, &, <, >.

XML Request Layout

<?xml version="1.0" encoding="utf-16"?>
<requestHeader>
	<ClientIdentifier/>
	<TransactionID/>
	<RequestType>019</RequestType>
	<RequestDateTime/>
	<User/>
	<Password/>
	<requestMessage>
		<MerchantCode>
			<MerchantCode>
				<MerchantAccountCode/>
				<Amount/>
				<ReferenceNumber/>
				<TransactionType/>
				<TransactionCode/>
				<FolioNumber/>
				<CheckInDate/>
				<Token/>
				<SettlementDelay/>
				<OriginatingTechnologySource/>
				<SoftwareVendor/>
				<SecurityTechnology/>
				<DeviceMake/>
				<DeviceModel/>
				<DeviceSerial/>
				<DeviceFirmware/>
				<RegistrationKey/>
				<AppHostMachineId/>
				<IntegrationMethod/>
			</requestMessage>
		</requestHeader> 

 

Response

The response message is included in the Capture element and returns the following data elements:

 

Parameter

Data Type

Length

Description 

R

ReferenceNumber

string

 

Provider supplied reference number.

R

GatewayResult

string

 

Echo of ResponseCode.

R

GatewayTransID

string

 

Echo of TransactionID.

R

GatewayMessage

string

 

Echo of ResponseDescription.

R

TransactionCode

string

 

The TransactionCode that was send with the request.

R

ResponseType

string

 

Action that was performed: “capture”.

R

MerchantAccountCode

string

 

The merchant account code used to process the original authorization and the void or refund.

XML Response Layout 

<?xml version="1.0" encoding="utf-16"?>
<Capture>
	<TransactionID/>
	<RequestType>019</RequestType>
	<ResponseCode>00000</ResponseCode>
	<responseMessage>
		<ReferenceNumber/>
		<GatewayResult/>
		<GatewayTransID/>
		<GatewayMessage/>
		<TransactionCode/>
		<ResponseType/>
		<MerchantAccountCode/>
	</responseMessage>
</Capture>

 


Initiate Settlement (Request 020)

This request method is used to initiate a settlement request immediately. All unsettled transactions will be submitted to the processors for settlement.

  This message requires no specific additional parameters apart from the base request, other than elements required            for merchant lookup. See section 1.6 for more information.

XML Request Layout 

<?xml version="1.0" encoding="utf-16"?>
<requestHeader>
	<ClientIdentifier/>
	<TransactionID/>
	<RequestType>020</RequestType>
	<RequestDateTime/>
	<User/>
	<Password/>
	<requestMessage>
		<MerchantCode/>
		<MerchantAccountCode/>
	</requestMessage>
</requestHeader>

Response

The response message is included in the CloseCycle element and returns the following data elements:

 

Parameter

Data Type

Length

Description

R

CycleCode

string

 

The Batch ID for the submitted transactions.

R

GatewayResult

string

 

Echo of ResponseCode.

R

GatewayTransID

string

 

Echo of TransactionID.

R

GatewayMessage

string

 

Echo of ResponseDescription.

R

TransactionCode

string

 

The TransactionCode that was send with the request.

R

ResponseType

string

 

Action that was performed: “closeCycle”.

R

MerchantAccountCode

string

 

The merchant account code used to process the original transactions.

XML Response Layout

<?xml version="1.0" encoding="utf-16"?>
<CloseCycle>
	<TransactionID/>
	<RequestType>020</RequestType>
	<ResponseCode>00000</ResponseCode>
	<responseMessage>
		<CycleCode/>
		<GatewayResult/>
		<GatewayTransID/>
		<GatewayMessage/>
		<TransactionCode/>
		<ResponseType/>
		<MerchantAccountCode/>
	</responseMessage>
</CloseCycle>


Find Transaction (Request 023)

This request method is used to retrieve transaction information.

The data elements for this request type are as follows:

 

Data Element

Date Type

Length

Description 

R

MerchantCode

integer

 

Provided by MyBridgePay at the time of boarding. The element is necessary unless the client is using a different merchant lookup solution (See Section 1.6). Used to narrow the search query down to a given merchant code.

R

MerchantAccountCode

integer

 

Provided by MyBridgePay at the time of boarding. The element is necessary unless the client is using a different merchant lookup solution (See Section 1.6). Used to narrow the search query down to a give merchant account code.

O

TransactionCode

string

 

Used to search on the user-provided transaction code of the transaction.

O

GatewayTransID

integer

 

Identifies the BridgePay Gateway ID number of the request.

O

PurchaseToken

GUID

36

Used to search for a transaction that was processed using the given Purchase Token.

O

InvoiceNum

string

24

Used to search on the user-provided Invoice Number of the original transaction.

All parameters are optional, however, if no parameters are provided, or if the results of the query return more than one row, BridgeComm will return an error indicating the need to restrict the search parameters.

XML Request Layout

<?xml version="1.0" encoding="utf-16"?>
<requestHeader>
	<ClientIdentifier/>
	<TransactionID/>
	<RequestType>023</RequestType>
	<RequestDateTime/>
	<User/>
	<Password/>
	<requestMessage>
		<GatewayTransID/>
		<MerchantCode/>
		<MerchantAccountCode/>
		<TransactionCode/>
		<PurchaseToken/>
		<InvoiceNum/>
	</requestMessage>
</requestHeader>

Response

The response message is included in the Find element and returns the following data elements:

 

Parameter

Data Type

Length

Description 

 

MerchantCode

integer

12

The default merchant code assigned to the user.

 

MerchantAccountCode

integer

 

The default merchant account code assigned to the user.

 

RoutingNumber

integer

 

The routing number for ACH and Check transactions.

 

PurchaseToken

GUID

36

Echo back of Purchase Token used in transaction request.

 

ApprovalCode

string

 

Transaction authorization code returned from the processor.

 

CSCResponseCode

string

1

The BridgePay Gateway CVV Result Code.

 

GatewayTransId

integer

 

Identifies the BridgePay Gateway ID number of the request.

 

HolderName

string

200

Displays the cardholder name as provided in the request message, or from the device.

 

InvoiceNum

string

24

Invoice number used in the transaction request.

 

TransactionDate

DateTime

14

Date of the request. Format: yyyyMMddHHmmss

 

TransactionCategory

string

1

Echo back of the transaction category code used in the transaction request.

 

Amount

integer

8

The implied decimal implementation of the authorized amount.

 

AVSResponseCode

string

 

Unipay AVS Match Result Code.

 

Balance 

integer

8

Amount of money remaining on the card. Provided as implied decimal. $1.25 would be represented as 125.

 

Email

string

100

Account holder’s e-mail address provided in the transaction request.

 

ExpirationDate

string

7

Echo back of the expiration date.

 

Holdertype

string

1

Echo back of the account holder type. Single character, either P (Personal account) or O (Organization account).

 

AccountType

string

2

Two-character code describing the type of account. See account type definitions later in this document.

 

City

string

 

Echo back of the billing address.

 

Memo

string

 

The memo field provided on the transaction

 

OriginalAmount

integer

8

The implied decimal implementation of the original amount.

 

Phone

string

 

The phone number provided in the transaction request.

 

Token

integer

22

The tokenized card number received from a token request or authorization. Note that the last four digits of the Token are the last four digits of the card number.

 

AccountNumberMasked

integer

 

Last 4 digits of truncated account number from transaction request.

 

CountryCode

string

 

Country code of billing address.

 

State

string

 

State of the billing address.

 

Street

string

 

Street of the billing address.

 

TransactionIndustryType

string

2-3

Echos back the industry type code used in the transaction request.

 

TransactionType

string

11

Echos back the transaction type used in the transaction request.

 

ZipCode

string

10

Zip code of billing address. 

 

PersistedData

string

 

XML representation of data elements with persist attribute. Returns any persisted data included in transaction request. (i.e. User Data, Invoice Number. See section A3.)

 

ResponseCode

string

5

Echo of the 5 digit ResponseCode returned on the transaction.

 

ResponseDescription

string

 

Echo of ResponseMessage returned on the transaction.

 

OriginalReferenceNumber

integer

 

If the transaction in question is a refund then the OriginalReferenceNumber value will be populated with the GatewayTransID of the original
sale.

XML Response Layout

<?xml version="1.0" encoding="utf-16"?>
<Find>
	<TransactionID/>
	<RequestType>023</RequestType>
	<ResponseCode/>
	<ResponseDescription/>
	<responseMessage>
		<RoutingNumber/>
		<PurchaseToken/>
		<ApprovalCode/>
		<CSCResponseCode/>
		<GatewayTransID/>
		<HolderName/>
		<InvoiceNum/>
		<MerchantCode/>
		<MerchantAccountCode/>
		<TransactionDate/>
		<TransactionCategory/>
		<Amount/>
		<AVSResponseCode/>
		<Balance/>
		<Email/>
		<ExpirationDate/>
		<HolderType/>
		<AccountType/>
		<City/>
		<Memo/>
		<OriginalAmount/>
		<Phone/>
		<Token/>
		<AccountNumber/>
		<CountryCode/>
		<State/>
		<Street/>
		<TransactionIndustryType/>
		<TransactionType/>
		<ZipCode/>
		<PersistedData/>
		<ResponseCode/>
		<ResponseDescription/>
		<OriginalReferenceNumber/>
	</responseMessage>
</Find>



Ping (Request 099)

Use the ping request to determine the status of the gateway.

  This message requires no additional parameters from the base request.

XML Request Layout

<?xml version="1.0" encoding="utf-16"?>
<requestHeader>
	<ClientIdentifier/>
	<TransactionID/>
	<RequestType>099</RequestType>
	<RequestDateTime/>
	<User/>
	<Password/>
	<requestMessage/>
</requestHeader>

Response

The response message is included in the Ping element with no extra data elements.

XML Response Layout

<?xml version="1.0" encoding="utf-16"?>
<Ping>
	<TransactionID/>
	<RequestType>099</RequestType>
	<ResponseCode>00000</ResponseCode>
	<ResponseDescription>SuccessfulRequest</ResponseDescription>
</Ping>




Generic Error Response

All of the service responses described in the preceding sections reflect a successful result. If the results of a specific request are not successful, a “generic error” response will be returned instead of a successful response. The generic error response returns the following parameters:

 

Parameter

Data Type

Length

Description

R

TransactionID

 

 

The TransactionID value submitted with the original request.

R

RequestType

 

 

The RequestType value from the original request that has failed.

R

ResponseCode

integer

5

A five-digit response code describing the results of the transaction. See Appendix A.1 for a list of valid response values.

R

ResponseDescription

string

 

Description of the error response code (ResponseCode).

Response Layout

The following is an example of an error response due to invalid access credentials (the TransactionID value would be the actual value from the initial service call that failed):

<?xml version="1.0" encoding="utf-16"?>
<ErrorResponse>
	<TransactionID>0312-7958-4465-0664</TransactionID>
	<RequestType>007</RequestType>
	<ResponseCode>10024</ResponseCode>
	<ResponseDescription>Invalid Credentials</ResponseDescription>
	<responseMessage/>
</ErrorResponse>

 



 

Appendix



ResponseCode Values

The following table displays the possible numeric values and descriptions returned by BridgePay in the ResponseCode field.

BridgePay Code

Description

00000

Successful request

10001

Missing Reference Number

10002

Invalid Card Number- Blank/Null

10003

Invalid Card Type - Doesn't match accepted card types

10004

Invalid Expiration Date - Blank/Null

10005

Invalid Security Code - Blank/Null

10007

Invalid Card Number - Not Numeric

10008

Invalid Length for card type

10009

Invalid Expiration Date - Card Expired

10010

Invalid Security Code - Not Numeric

10011

Invalid Transaction ID

10012

Invalid Card Number - Failed Mod10

10013

Invalid Expiration Date Value

10014

Invalid Security Code Length

10017

Invalid Expiration Date - Invalid Month

10018

Invalid Expiration Date - Invalid Year

10019

Invalid Expiration Date

10020

Invalid Client Identifier

10021

Invalid Request Element – Missing Element

10022

Invalid Request Type

10023

Password Expired

10024

Invalid Credentials

10025

Invalid Zip – Not Numeric

10026

Invalid Zip – Wrong Length

10027

Invalid Amount – Blank/Null

10028

Invalid Amount – Not Numeric

10029

Invalid Request Date/Time

10030

Invalid Token

10031

Invalid Track

10032

Invalid Track Identifier

10033

Invalid Void Request

10034

Invalid Encryption ID

10035

Invalid Account Number – Blank/Null

10036

Invalid Account Number – Not Numeric

10037

Invalid Payment Type – Blank/Null

10038

Invalid Payment Type – Unrecognized Payment Type

10039

Invalid Account Number – Account Number Does Not Exist

10040

Missing Required Pass-Thru Data Element

10041

Missing / Invalid BIN

10042

Already Voided

10050

Incorrect Trace Number

10051

Incorrect Merchant Setup

10052

Processing Network Error

10053

Credit Card Entry Refused by Receiver

10054

Mandatory Field Error

10055

Invalid Reference Number

20001

Tokenization Service Connection Error

20002

BridgePay Internal Server Error

20003

Client Service Unavailable

20004

Payment Service Sensitive Data Timeout

30004

Invalid Request Message

30005

Invalid Response Message

30006

New Password Doesn't Match Confirmation Password

30007

New Password Too Weak*

30008

Missing Payment Card Data

30009

Internal Payment Card Data Error

30010

Invalid Record Format

30011

Invalid Merchant Number (from Gateway)

30012

Bad Card Number (from Gateway)

30013

Invalid Store Number

30020

Invalid Transaction Industry Type

30021

Missing Transaction Industry Type

30022

Processing Network Unavailable

30023

Invalid Account Number

30024

No Account

30025

Invalid Security Code

30026

Invalid Amount

30027

Refund limit is reached for the day(occurs when merchant has reached the refund limit allowed per day on the account)

30028

Settlement Failed

30029

Transaction Error

30030

Transaction data integrity validation error

30032

Denied by customer’s bank

30033

Insufficient funds

30034

Hold - Pick up card

30035

Incorrect PIN

30036

Duplicate Transaction

30037

Card reported lost

30038

Card reported stolen

30039

Service not allowed

30040

Stop Recurring

30041

Unattempted Batch Decline

30042

Maximum transaction limit is exceeded at the moment. Try processing your transaction tomorrow.

30043

Re-enter Transaction

30044

Unmapped decline

30045

Billing profile configuration error

30046

Pin Try Exceeded

30047

Refund was not processed/received

30048

Chargeback received

30049

Processing Canceled by User

30050

Invalid Transaction Category

30051

Invalid Verification Status

30052

Invalid Terminal Type

30053

Invalid Petroleum Product Type

30060

Invalid IApp User Id

30061

Account insert failed

30062

Merchant insert failed

30070

New Password Previously Used

30071

Missing Clerk Id

30072

Call for Authorization

30073

Card is Restricted

30074

Declined due to fraud rules

30075

Bank Account Blacklisted

30076

Declined due to insufficient information

30077

Rejected by the processor

30078

Account Closed

30079

Invalid Account

30080

Account can not process ACH

30082

Invalid MICR

30083

Customer opt out check Conversion

30084

Transaction exceeds max single transaction threshold

30085

Transaction exceeds max total threshold

30100

Invalid Account Data – Blank/Null

30101

Invalid EMV Tag Data – Blank/Null

30102

Surcharge are not allowed 

30103

Cashback is not available 

30104

Routing Number/Check Digit Error 

30105

Transaction not premitted - card

30106

Transaction not premitted - terminal 

30107

Issuer Unavailable 

40001

Lodging Reauth Failed

40002

Missing Lodging Folio Number

80000

Gateway Services Available

80001

Gateway Services Unavailable

80002

Invalid Purchase Token

80003

More than one result found for search criteria

80004

More than one service fee block received in request message

80005

Cascade Void. Indicates that the transaction was successfully authorized (fully or partially) and then voided due to an auto-void policy setting. Only occurs on principal transactions and only when the accompanying service fee was either declined or voided due to an auto-void policy setting.

80006

Partial Auto Void. Indicates that the transaction was partially authorized and then voided due to an auto-void policy setting.     Can occur on a service fee or principal transaction.

80007

Database query processing error. Can occur on a Find Transaction request if the data requested is unavailable.

80008

Invalid GatewayTransID

80009

Invalid MerchantCode

80010

Invalid MerchantAccountCode

80011

Transaction not found

80012

Invalid Length for PersistData

80013

Invalid ActionType

80014

Invalid Device

80015

Adjustment Failure

90000

Token Store failed to encrypt a token

90001

Token Store failed to decrypt a token

90002

Unauthorized Access

90003

Custom Field Name Does Not Exist

90004

Unreadable XML Request Message

99999

Unknown Error


Account Type Definitions

BridgePay Code

Description

AC

American Express

DC

Discover Credit

DD

Discover Debit

NC

Diner's

MC

MasterCard Credit

MD

MasterCard Debit

VC

Visa Credit

VD

Visa Debit

BS

Bank Savings Account

BC

Bank Checking Account

BD

Bank Card Debit

EF

Food Stamp

EC

Cash Benefit

MP

MasterCard Prepaid

MF

MasterCard Fleet

VP

Visa Prepaid

VS

Visa Fleet

GG

General Gift

FL

Fleet One

GF

Fuel Man Fleet Wide

VF

Voyager

WX

Wright Express

CS

Cash

CK

Check

VE

Visa Debit Checking

VV

Visa Debit Savings

FU

Fuel Lynk

BN

Bank Card Debit Checking

BI

Bank Card Debit Savings

 


Persist Attribute

Request Messages that result in a stored transaction can now utilize a new attribute named persist that will force the gateway to store any elements passed in with that value. This can be valuable for later research. This option is available for known* and unknown data elements, thereby allowing merchants to store data that BridgeComm would not normally store. The data elements marked with the persist attribute are concatenated in XML format and stored in a single field in the database and cannot be used for searching, however the data is retrievable via the Find (023) request. This field should not be used to store protected cardholder information.

Example 1: Forcing the Invoice Number field to be included in the persisted data field.

<?xml version="1.0" encoding="utf-16"?>
<requestHeader>
	<ClientIdentifier/>
	<TransactionID/>
	<RequestType/>
	<RequestDateTime/>
	<User/>
	<Password/>
	<requestMessage>
      ...
     <InvoiceNumber persist=”true”></InvoiceNumber> ...
  </requestMessage>
</requestHeader>


 
Example 2: Forcing a user-defined field called UserData to be included in the persisted data field.

<?xml version="1.0" encoding="utf-16"?>
<requestHeader>
	<ClientIdentifier/>
	<TransactionID/>
	<RequestType/>
	<RequestDateTime/>
	<User/>
	<Password/>
	<requestMessage>
		...
		<UserData persist=”true”>
		</UserData> ...
	</requestMessage>
</requestHeader>

Some known data elements will not store as they are protected by PCI requirements (e.g. Account Numbers, Track Data and Passwords).


Base64-Encoded SOAP Message Sample

The following message samples show the proper way to base64 encode a request message and the resulting base64-encoded response message:

Request Message

<!--AuthTest_BadClientID-->
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:req="http://bridgepaynetsecuretx.com/requesthandler">
	<soapenv:Header/>
	<soapenv:Body>
		<req:ProcessRequest>
</req:requestMsg>
PHJlcXVlc3RIZWFkZXI+DQogIDxDbGllbnRJZGVudGlmaWVyPkJhZDwvQ2xpZW50SWRlbnRpZmllcj4NCiAgPFRyYW5zYWN0a
W9uSUQ+MTAwMTwvVHJhbnNhY3Rpb25JRD4NCiAgPFJlcXVlc3RUeXBlPjAwNDwvUmVxdWVzdFR5cGU+DQogIDxSZXF1ZXN0RG
F0ZVRpbWU+MDIvMTIvMjAxMjwvUmVxdWVzdERhdGVUaW1lPg0KICA8RG9tYWluPmRvbWFpbjwvRG9tYWluPg0KICA8VXNlcj5
1c2VyPC9Vc2VyPg0KICA8UGFzc3dvcmQ+cGFzczwvUGFzc3dvcmQ+DQogIDxyZXF1ZXN0TWVzc2FnZT4NCgk8UGF5bWVudEFj
Y291bnROdW1iZXI+NTEwNTEwNTEwNTEwNTEwMDwvUGF5bWVudEFjY291bnROdW1iZXI+DQoJPFNpdGVDb2RlPjAwMDA8L1Npd
GVDb2RlPg0KCTxab25lQ29kZT4wMDAxPC9ab25lQ29kZT4NCgk8RXhwaXJhdGlvbkRhdGU+MDMyMDE0PC9FeHBpcmF0aW9uRG
F0ZT4NCgk8WmlwQ29kZT4zNDk1MjwvWmlwQ29kZT4NCgk8Q2FyZFNlY3VyaXR5Q29kZT45OTk8L0NhcmRTZWN1cml0eUNvZGU
+DQoJPEFtb3VudD4xNTAuMDA8L0Ftb3VudD4NCiAgICAgICAgPEVuY3J5cHRpb25JRD4yMDEyMDgxNDA2NzM1NDI8L0VuY3J5
cHRpb25JRD4NCiAgPC9yZXF1ZXN0TWVc2FnZT4NCjwvcmVxdWVzdEhlYWRlcj4=
</req:requestMsg>
</req:ProcessRequest>
</soapenv:Body>
</soapenv:Envelope>

Response Message

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
	<s:Body>
		<ProcessRequestResponse xmlns="http://bridgepaynetsecuretx.com/requesthandler">
			<ProcessRequestResult>
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTE2Ij8+DQo8RXJyb3JSZXNwb25zZSB4bWxuczp4c2k9Imh0dHA6L
y93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp4c2Q9Imh0dHA6Ly93d3cudzMb3JnLzIwMDEvWE
1MU2NoZW1hIj4NCiAgPFRyYW5zYWN0aW9uSUQ+MTAwMTwvVHJhbnNhY3Rpb25JRD4NCiAgPFJlcXVlc3RUeXBlPjAwNDwvUmV
xdWVzdFR5cGU+DQogIDxSZXNwb25zZUNvZGU+MTAwMjA8L1Jlc3BvbnNlQ29kZT4NCjwvRXJyb3JSZXNwb25zZT4=
</ProcessRequestResult>
		</ProcessRequestResponse>
	</s:Body>
</s:Envelope>


Industry Specific Fields

Depending upon the industry, you can receive better transaction rates by specifying your industry and including industry specific fields in transaction requests. This appendix provides information for each specialized industry and what fields you can use to support these transactions.

Lodging

 

Parameter

Data Type

Length

Description 

O

RoomNumber

string

25

Hotel room number

C

FolioNumber

string

15

Hotel folio number
Required when LodgingChargeType = 'H'

C

RoomRateAmount

integer

8

Daily room rate. Implied decimal.
Required when LodgingChargeType = 'H'

O

RoomTaxAmount

integer

8

Tax charged on daily rate. Implied decimal.

R

LodgingChargeType

Enum

 

Type of service for which this transaction is processed.

  • H = Hotel

  • R = Restaurant

  • G = Gift Shop

  • S = Health Spa

  • B = Beauty Shop

  • F = Convention Fee

  • T = Tennis

  • O = Golf

C

CheckInDate

Date

 

The date of actual or anticipated check-in.
Required when LodgingChargeType = 'H'

C

CheckOutDate

Date

 

The date of actual or anticipated check-out
Required when LodgingChargeType = 'H'

O

StayDuration

integer

 

Indicates the length of anticipated, actual or incremental stay.

C

SpecialProgramType

Enum

 

Important when the cardholder did not stay at the hotel.

  • AD = Advance deposit

  • AR = Assured reservation

  • DC = Delayed charge

  • ES = Express service

  • NC = Normal charge

  • NS = No show charge

Required when LodgingChargeType = 'H'

O

DepartureAdjAmount

integer

8

Additional amount charged after the cardholder left the hotel.

C

LodgingItemCount

integer

 

Conditional, required if lodging items present in request. Indicates number of lodging industry items purchased as part of this transaction. See Lodging Item Records for more detail.
Required when LodgingChargeType = 'H'

C

LodgingItems

Collection

 

Collection of lodging item records.

Lodging Item Records

Clients processing lodging industry transactions and desiring to itemize the charges for additional service can include lodging items sub-records as a part of the request message. When lodging item information is supplied, the client is required to indicate the number of sub-records in the LodgingItemCount field.

 

Parameter

Data Type

Length

Description

R

LodgingItemType

Enum

 

Lodging extra charge type

  • G = Gift Shop

  • L = Laundry

  • B = Mini bar

  • R = Restaurant

  • T = Telephone

R

LodgingItemAmount

integer

8

Amount for lodging extra charge item. Implied decimal.

Examples
To process an authorization or capture via the ProcessRequest access method for a merchant using lodging industry fields, the RequestMessage element would have the following tags embedded within it:

<?xml version="1.0" encoding="utf-16"?>
	<requestHeader>
	.
	.
	.
		<requestMessage>
		.
		.
		.
		<RoomNumber/>
		<FolioNumber/>
		<RoomRateAmount/>
		<RoomTaxAmount/>
		<LodgingChargeType/>
		<CheckInDate/>
		<CheckOutDate/>
		<StayDuration/>
		<SpecialProgramType/>
		<DepartureAdjAmount/>
		<LodgingItemCount/>
		<LodgingItem>
			<LodgingItemType/>
			<LodgingItemAmount/>
		</LodgingItem>
		.
		.
		.
	</requestMessage>
</requestHeader>

 

Car Rental 

 

Parameter

Data Type

Length

Description

R

RentalAgreementNumber

string

25

Car Rental Agreement Number. Required as part of the Rental Key.

O

RentalDailyRateAmount

integer

8

Total rent amount per day. Implied decimal.

R

RentalDuration

integer

4

Car Rental Period.

O

RentalExtraChargesAmount

integer

8

Can rental special services amount. Implied decimal.

O

RentalInsuranceAmount

integer

8

Car insurance amount. Implied decimal.

O

MaxFreeMiles

integer

8

Total mileage for rent period.

O

MileRateAmount

integer

8

Total rent amount per mile. Implied decimal.

R

RentalName

string

20

Name of the person who rented the car.

O

RentalCity

string

25

City where the car rental starts.

O

RentalCountryCode

string

2

Country where the car rental starts.

R

RentalDate

date

10

Date when the car rental starts. (MM/DD/YYYY format)

O

RentalState

string

3

State where the car rental starts.

O

RentalTime

integer

4

Car rental start time in 24-Hour Format. (HHMM)

O

ReturnLocationCode

string

10

Identification code of the place where car was returned.

O

ReturnCity

string

25

City where the car is returned

O

ReturnCountryCode

string

2

Country where the car is returned.

R

ReturnDate

date

10

Date when the car should be returned.

O

ReturnState

string

3

State where the car is returned.

O

ReturnTime

integer

4

Time when the car should be returned in 24-Hour Format. (HHMM)

R

RentalSpecialProgramType

string

2

String based enum representing the special program type for the rental.
Accepted values are AD (Advance Deposit), AR (Assured Reservation),
DC (Delayed Charge), ES (Express Service), NC (Normal Charge),
and NS (No Show Charge).

O

TotalMiles

integer

8

Rented car total mileage (miles on car)

O

RentalExtraChargeItemCount

integer

4

Count of extra charges included in the transaction.

O

RentalExtraChargeItems

Collection

n/a

List of extra charges. See below.

Car Rental Item Records
Clients processing car rental industry transactions and desiring to itemize the charges for additional service can include car rental items sub-records as a part of the request message. When car rental item information is supplied, the client is required to indicate the number of sub-records in the RentalExtraChargesItemCount field.

 

Parameter

Data Type

Length

Description

R

RentalExtraChargeItemType

Enum

 

Car rental extra charge type

  • M = Extra Mileage

  • S = Gas

  • N = Late Return

  • W = One-Way Service

  • P = Parking Violation

R

RentalExtraChargeTypeAmount

integer

8

Amount for car rental extra charge item. Implied decimal.

Examples
To process an authorization or capture via the ProcessRequest access method for a merchant using car rental industry fields, the RequestMessage element would have the following tags embedded within it:

<?xml version="1.0" encoding="utf-16"?>
<requestHeader>
	<requestMessage>
		<RentalName/>
		<RentalCity/>
		<RentalState/>
		<RentalCountryCode/>
		<RentalDate/>
		<RentalTime/>
		<ReturnCity/>
		<ReturnState/>
		<ReturnCountryCode/>
		<RentalExtraChargesAmount/>
		<ReturnDate/>
		<ReturnTime/>
		<RentalAgreementNumber/>
		<RentalDailyRateAmount/>
		<RentalDuration/>
		<RentalInsuranceAmount/>
		<MaxFreeMiles/>
		<MileRateAmount/>
		<ReturnLocationCode/>
		<RentalSpecialProgramType/>
		<TotalMiles/>
		<RentalExtraChargesItemCount/>
		<RentalExtraChargeItem>
			<RentalExtraChargeItemType/>
			<RentalExtraChargeItemAmount/>
		</RentalExtraChargeItem>
	</requestMessage>
</requestHeader>

Performing Grouped Authorizations & Captures

Initial Authorizations

The formatting and content of a transaction request to BridgeComm will identify whether the request is an initial authorization or an incremental authorization. A series of transactions for lodging, with future support for Car Rental, are identified by a transaction group key. The group key is comprised of four data elements: the card number/token, the check-in date or rental date, the folio number or rental agreement number and the merchant lookup information.

When sending a grouped transaction to BridgeComm, the key is constructed based on the data elements mentioned above. If the transaction is the first transaction using that key, an initial authorization is created and the settlement delay is set to either the duration of the stay or the difference between the check-in date (rental start) and the check-out date (rental end).

For Car Rental transactions, provide all required fields to process a sale-auth. The GatewayTransID for this sale will be used for subsequent follow-on transactions as the ReferenceNumber. The group key will not be used for incremental authorizations and capture.

Incremental Authorizations

Incremental authorizations can be generated in one of two ways. The originating system can either send an incremental request by providing the amount to increment the total, or by sending the new total. For example, if the initial authorization is $250.00, to increase the total authorization amount to $300.00, the originating system can either send a $50.00 incremental message, or a $300.00 total message. Both operations end up in acquiring only $50.00 more for the key.

To send an incremental authorization with only the delta amount, the message to BridgeComm will set the TransactionType field to increment, and send the incremental amount in the Amount field. The originating system must also include all other elements required to process the transaction. For Lodging transactions, use the transaction group key described in the prior section to link the increment. For Car Rental transactions, use the GatewayTransID of the original sale-auth, as the ReferenceNumber to link the transactions. 

To send an incremental authorization be specifying the new total amount, the message to BridgeComm will set the TransactionType field to sale-auth, and send the new total amount in the Amount field. The originating system must also include all other elements required to process the transaction. Note that this functionality is only available for Lodging. For Car Rental, use the increment transaction type with the ReferenceNumber mentioned above.

Capture/Check-Out/Return

The capture process for a group of authorizations for a key is handled in much the same way. It is not necessary to capture each individual authorization. Instead, for Lodging transactions, the merchant sends a capture request (See 2.2.11 – Capture Request) including the Card Number or Token, Check-In Date, Folio Number (or Rental Agreement Number) and Merchant Identification information. All authorizations for that key are then totaled and captured as one transaction in preparation for settlement.

For Car Rental transactions, Capture must be performed using the GatewayTransID of the original sale-auth as the ReferenceNumber, like the increment transaction type. 

If the final amount of the transaction is different than the amount authorized to date, the merchant can also send the final amount with the capture message. This will trigger either a partial reversal (if the final amount is less than the total authorized to date amount) or a final incremental authorization (if the final amount is greater than the total authorized to date amount). This capture method also disables the settlement delay, allowing the transaction to be included in the next settlement batch.

Healthcare 

When processing a healthcare industry transaction (using an FSA or HSA account) additional amount fields need to be specified. The only amount that is required is HealthCareAmt, while other amounts are optional. If medical transportation was involved, then TransitAmt should be added.

Depending on the type of service rendered, additional amounts can be specified to HealthCareAmt to indicate how much was spent on prescription, vision/optical, dental and clinic/hospitalization services. The total of prescription, vision, dental and clinic amounts can be less than or equal to HealthCareAmt.
 

 

Parameter

Data Type

Length

Description

R

HealthCareAmt

integer

8

Indicates the portion of the amount field that was spent on healthcare-related services. Implied decimal.

O

TransitAmt

integer

8

Indicates the portion of the amount field that was spent on healthcare-related transportation. Implied decimal.

O

PrescriptionAmt

integer

8

Indicates the portion of the HealthCareAmt field that was spent on prescription drugs. Implied decimal.

O

VisionAmt

integer

8

Indicates the portion of the HealthCareAmt field that was spent on vision-related (optical) medical services. Implied decimal.

O

DentalAmt

integer

8

Indicates the portion of the HealthCareAmt field that was spent on dental medical services. Implied decimal.

O

ClinicAmt

integer

8

Indicates the portion of the HealthCareAmt field that was spent on hospitalization. Implied decimal.

O

IsQualifiedIIAS

Boolean

 

Indicates whether items purchased were verified against IIAS as qualified for healthcare purchases. Value must be True or False.

Examples

<?xml version="1.0" encoding="utf-16"?>
<requestHeader>
.
.
.
	<requestMessage>
		.
		.
		.
		<TransCatCode>H</TransCatCode>
		<HealthCareAmt/>
		<TransitAmt/>
		<PrescriptionAmt/>
		<VisionAmt/>
		<DentalAmt/>
		<ClinicAmt/>
		<IsQualifiedIIAS/>
		.
		.
		.
	</requestMessage>
</requestHeader>


Track Data Handling

If you are sending track data to BridgeComm, there are two ways of sending the data. You may choose the integration specifics that work best for you. The options are Combined Track Information (CTI) or Split Track Information (STI).

Combined Track Information (CTI)

If your integration requires sending track information all in one field, you can use either the TrackData element or the Track element to send the data. It should contain both Track 1 and Track 2 concatenated and sent in one string.

To send the data without extra encryption, simply concatenate the two fields with no extra spaces. You must include all start and end sentinels and the field separators as well.

To send the data with hardware level encryption, your reader must support encrypting combined track data. This encrypted combined track data would then be placed in the TrackData or Track element.

Split Track Information (STI)

If your integration requires sending track information in separate fields, you can use the Track1 and Track2 data elements to send the data.

To send the data without extra encryption, simply send the appropriate data elements in the appropriate fields. You must include all start and end sentinels and the field separators as well.

To send the data with hardware level encryption, your reader must provide the encrypted data in separate fields. This encrypted combined track data would then be placed in the Track1 and Track2 elements respectively.

RSA level encryption is not available for Split Track Information. To use RSA level encryption, you will need to send the data using the CTI method described above.

 

Purchase Tokens

If you wish to use Purchase Tokens to further secure your payment transactions, you must first acquire a purchase token from BridgeComm. A Purchase Token is valid for exactly one transaction and only for 15 minutes after creation. This appendix describes how to acquire and consume a purchase token.

The following URL should be used as the SOAPAction value in the POST headers:

https://bridgepaynetsecuretx.com/actionservice/IActionService/AcquirePurchaseToken

Below is a link to a Postman sample for testing

Action Service (Purchase Tokens).postman_collection.json

Acquiring a Purchase Token

To acquire a purchase token, your application must consume the AcquirePurchaseToken method on the ActionService web service.

string AcquirePurchaseToken(string userName, string password, string certificationId, int transactionAmount, string purchaserInfo, string transactionInfo

 

 

Parameter

Data Type

Length

Description

R

userName

string

 

The username assigned for accessing BridgeComm

R

password

string

 

The password assigned to the user for accessing BridgeComm

O

certificationId

string

 

Not required. Default to and empty string. Reserved for future use.

R

transactionAmount

Int

8

The implied decimal amount of the transaction being preauthorized. (e.g. 125 for a $1.25 authorization)

O

purchaserInfo

string

 

Not required. A merchant provided string identifying the customer account the transaction is for. Compared with CustomerAccountCode element in the transaction request.

O

transactionInfo

string

 

Not required. A merchant provided string identifying the invoice the transaction is for. Compared with the InvoiceNum element in the transaction request.

When BridgeComm receives a request for a new purchase token, BridgeComm will first look to see if a purchase token for a similar request using the same data elements has already been generated and not yet consumed. If so, no new purchase token will be generated and the service will return an empty string.

If no existing purchase token exists, one will be generated and returned to the merchant.

Consuming a Purchase Token

Once the merchant has received a purchase token, the merchant has 15 minutes to use the token. To consume the token, the merchant must send the purchase token in the authorization request and all information used to create the purchase token must be included in the request.

If the merchant included the purchaserInfo in the request to acquire a purchase token, that data must be included in the CustomerAccountCode element of the transaction request.

If the merchant included the transactionInfo in the request to acquire a purchase token, that data must be included in the InvoiceNum element of the transaction request.

Example

  1. Merchant calls AcquirePurchaseToken

    1. AcquirePurchaseToken("user","password","",500,"12345","98765")

  2. Merchant receives Purchase Token

    1. returnValue = “0E0D6C55-AF5E-49AE-8DE7-001B08A550CF”

  3. Merchant calls ProcessRequest

ProcessRequest("

requestHeader>
	<ClientIdentifier>SOAP</ClientIdentifier>
	<TransactionId>1234567890</TransactionId>
	<RequestType>004</RequestType>
	<RequestDateTime>2015-01-01</RequestDateTime>
	<requestMessage>
			...
			<PurchaseToken>0E0D6C55-AF5E-49AE-8DE7-001B08A550CF </PurchaseToken>
			<Amount>500</Amount>
			<CustomerAccountCode>12345</CustomerAccountCode>
			<InvoiceNum>98765</InvoiceNum>
			...
	</requestMessage>
</requestHeader>

Other Uses of Purchase Tokens

Once acquired, a Purchase Token can be used in a Get Merchant Info request (011) or a Multi-Use Token request (001) within the 15 minute time period without consuming the purchase token. This allows for a consumer to work with the same purchase token if there are informational requirements that must be met before completing the transaction.

After a Purchase Token is consumed, it can still be used for Voiding or Refunding the original authorization or Sale that consumed the token. The Void/Refund operation can only be performed once per consumed Purchase Token.

EMV Processing

Processing EMV transactions through BridgeComm requires that the merchant provide a few more details in the transaction request. If the EMV reader is an encrypted reader, the merchant will also need to send the encrypted swipe data to BridgeComm as well to achieve tokenization.

Field Requirements

  • EMVTags – This element contains all the EMV tags returned from the EMV reader, combined into a single string using TLV encoding.

  • EntryMode – This field identifies how the transaction was processed by the terminal.

  • EntryMedium – This field identifies what type of media was used to collect the transaction.

  • EntryPINMode – This field identifies whether the media used provides PIN features.

  • TerminalCapabilities – This field identifies the capabilities of the terminal used to collect the data.

EMV Fields Example (Unencrypted)

<requestHeader>
	<ClientIdentifier/>
	<TransactionID>XXXX-XXXX-XXXX-XXXX</TransactionID>
	<RequestType>004</RequestType>
	<RequestDateTime>01/01/2015</RequestDateTime>
	<User>mbpUser</User>
	<Password>mbpPassword</Password>
	<requestMessage>
		<transindustrytype>RE</transindustrytype>
		<TransactionType>sale-auth</TransactionType>
		<AcctType>R</AcctType>
		<Amount>1000</Amount>
		<MerchantCode>1000</MerchantCode>
		<MerchantAccountCode>1001</MerchantAccountCode>
		<HolderType>P</HolderType>
		<EMVTags>4F07A0000000031010500A5669736120446562697457104450649200973734D19092260003680F82023C008407A
0000000031010950508000000009A03150439B02E8009C01005F2A0208405F3401019F02060000000005009F0607A0000000
0310109F0902008C9F100706010A03A020009F120A5669736120446562697491A0208409F1E0838303234373636319F21032
109149F2608FA940EE08082F8A59F2701809F3303E0B8C89F34031E03009F3501229F360200109F37043F2BE809F3901059F
4005F000F0A0019F4104000003819F530152</EMVTags>
		<EntryMedium>CC</EntryMedium>
		<EntryMode>HP</EntryMode>
		<EntryPINMode>X</EntryPINMode>
		<TerminalCapabilities>unknown|unused|manual|stripe|barcode|qrcode|ocr|icc|contactless|signature|rfid|
cr</TerminalCapabilities>
	</requestMessage>
</requestHeader> 

EMV Fields Example (Encrypted)

<requestHeader>
	<ClientIdentifier>clientId</ClientIdentifier>
	<TransactionID>XXXX-XXXX-XXXX-XXXX</TransactionID>
	<RequestType>004</RequestType>
	<RequestDateTime>01/01/2015</RequestDateTime>
	<User>mbpUser</User>
	<Password>mbpPassword</Password>
	<requestMessage>
		<transindustrytype>RE</transindustrytype>
		<TransactionType>sale-auth</TransactionType>
		<AcctType>R</AcctType>
		<Amount>1000</Amount>
		<MerchantCode>1000</MerchantCode>
		<MerchantAccountCode>1001</MerchantAccountCode>
		<HolderType>P</HolderType>
		<Track>9990A46CC78D0CDACA4CB5A3F9A73A4CEF1127B642BD11A4CF89E290EB96CFF1C745CC6AB9D64E53</Track>
		<SecureFormat>SecureMag</SecureFormat>
		<EMVTags>4F07A000000004101050104465626974204D61737465724361726457105128570000000856D1708622000000008202
39008407A000000004101095050400200009A031505089B02E8009C01005F2A0208405F3401009F02060000000012009F0607A
00000000410109F090200029F10120110A000002A000000000000000000000FF9F12104465626974204D617374657243617264
9F1A0208409F1E0838303138393539369F21031116219F26087FE93875A4F4F3899F2701809F3303E0BC89F34031E03009F350
1229F360202229F37044BB2D57D9F3901059F4005F000F0A0019F4104000005659F530152</EMVTags>
		<EntryMedium>CC</EntryMedium>
		<EntryMode>HP</EntryMode>
		<EntryPINMode>X</EntryPINMode>
		<TerminalCapabilities>unknown|unused|manual|stripe|barcode|qrcode|ocr|icc|contactless|signature|rfid|mi
cr</TerminalCapabilities>
	</requestMessage>
</requestHeader>




ACH Processing

The BridgePay Gateway supports ACH processing through 004 requests much like credit card transactions; however, certain fields change. For example, instead of the PaymentAccountNumber number and ExpirationDate, you must provide a BankAccountNum and RoutingNum. TransIndustryType must also be specified for the type of ACH transaction being processed. The AccountType will indicate whether the account was a Checking account or Savings.

Other transaction fields and the request structure are identical to the primary 004 structure.

Below are the relevant field requirements:

Field Requirements

  • TransIndustryType - ACH supported values are: CCD (Corporate Credit or Debit), PPD (Prearranged Payment and Deposit Entry), POP (Point of Purchase Entry), TEL (Telephone Initiated Entry), and WEB (Internet Initiated Entry).

  • AccountType - When sending a Check21 transaction, this field should be provided in the same manner as an ACH transaction with either C for checking or S for saving account.

  • BankAccountNum - As with any ACH transaction, this field must contain the account number of the transaction.

  • RoutingNum - As with any ACH transaction, this field must contain the routing number associated with the account number.





Non Gateway Transactions (Check/Cash)

BridgeComm is able to record transactions that did not occur within the gateway such as Check and Cash transactions. To record a transaction of this nature, the merchant must send specific values to identify it as a Cash or Check transaction.

Field Requirements

  • TransactionType – When sending a Check transaction or a Cash transaction, this field must be set to sale-info for transactions that represent income to the merchant or credit-info for transactions that represent refunds or other credits the merchant is making for a customer.

  • AccountType – If the request is recording a cash transaction, the AccountType field should be set to A. If the request is recording a physical check transaction, the AccountType field should be set to K.

  • CheckImageFront – If the request is recording a check transaction, the merchant can provide an image of the front of the check using this field.

  • CheckImageBack – If the request is recording a check transaction, the merchant can provide an image of the back of the check using this field.

  • MICR – If the request is recording a check transaction, the merchant can provide the MICR data associated with the check in this field.

Cash Fields Example

<requestHeader>
	<ClientIdentifier>clientId</ClientIdentifier>
	<TransactionID>XXXX-XXXX-XXXX-XXXX</TransactionID>
	<RequestType>004</RequestType>
	<RequestDateTime>01/01/2015</RequestDateTime>
	<User>mbpUser</User>
	<Password>mbpPassword</Password>
	<requestMessage>
		<transindustrytype>RE</transindustrytype>
		<TransactionType>sale-info</TransactionType>
		<AcctType>A</AcctType>
		<Amount>1000</Amount>
		<MerchantCode>1000</MerchantCode>
		<MerchantAccountCode>1001</MerchantAccountCode>
	</requestMessage>
</requestHeader> 

Check Fields Example

<requestHeader>
	<ClientIdentifier>clientId</ClientIdentifier>
	<TransactionID>XXXX-XXXX-XXXX-XXXX</TransactionID>
	<RequestType>004</RequestType>
	<RequestDateTime>01/01/2015</RequestDateTime>
	<User>mbpUser</User>
	<Password>mbpPassword</Password>
	<requestMessage>
		<transindustrytype>RE</transindustrytype>
		<TransactionType>sale-info</TransactionType>
		<AcctType>K</AcctType>
		<CheckImageFront>base64EncodedTIFFImage</CheckImageFront>
		<CheckImageBack>base64EncodedTIFFImage</CheckImageBack>
		<MICR>:021000021:4099999992&lt;1001</MICR>
		<Amount>1000</Amount>
		<MerchantCode>1000</MerchantCode>
		<MerchantAccountCode>1001</MerchantAccountCode>
	</requestMessage>
</requestHeader> 

  


Check21 Processing

Processing with Check21 services is similar to ACH processing. In order to process via Check21, the merchant must identify the transaction as a Check21 transaction and provide images of both the front and back of the physical check, along with the MICR data retrieved from the check reader.

Field Requirements

  • TransIndustryType – When sending a Check21 transaction this field must be set to C21.

  • AccountType – When sending a Check21 transaction, this field should be provided in the same manner as an ACH transaction with either C for checking account or S for saving account.

  • BankAccountNum – As with any ACH transaction, this field must contain the account number of the transaction.

  • RoutingNum – As with any ACH transaction, this field must contain the routing number associated with the account number.

  • CheckImageFront – If the request is recording a check transaction, the merchant can provide an image of the front of the check using this field.

  • CheckImageBack – If the request is recording a check transaction, the merchant can provide an image of the back of the check using this field.

  • MICR – If the request is recording a check transaction, the merchant can provide the MICR data associated with the check in this field.

Check 21 Fields Example

<requestHeader>
	<ClientIdentifier>clientId</ClientIdentifier>
	<TransactionID>XXXX-XXXX-XXXX-XXXX</TransactionID>
	<RequestType>004</RequestType>
	<RequestDateTime>01/01/2015</RequestDateTime>
	<User>mbpUser</User>
	<Password>mbpPassword</Password>
	<requestMessage>
		<transindustrytype>C21</transindustrytype>
		<TransactionType>sale</TransactionType>
		<AcctType>C</AcctType>
		<BankAccountNum>021000021</BankAccountNum>
		<RoutingNum>4099999992</RoutingNum>
		<CheckImageFront>base64EncodedTIFFImage</CheckImageFront>
		<CheckImageBack>base64EncodedTIFFImage</CheckImageBack>
		<MICR>:021000021:4099999992&lt;1001</MICR>
		<Amount>1000</Amount>
		<MerchantCode>1000</MerchantCode>
		<MerchantAccountCode>1001</MerchantAccountCode>
	</requestMessage>
</requestHeader> 





Gift Card

BridgeComm can now process Gift Card transactions using the standard 004 request type.
This section will not describe the entire 004 request type. Instead, it will highlight the data elements, and their values, that are required to process a Gift Card transaction.

Request

 

Data Element

Data Type

Length

Description

R

AcctType

string

1

Single character, must be set to G

R

TransactionType

string

11

Can contain letters and hyphens. Possible values are sale and credit.

All other fields are handled as normal. Use sale to process a transaction that will debit the gift card. Use credit to process a transaction that will credit the gift-card. All other request types (012 – VoidRefund, 019 – Capture) will be handled normally.

Manage Gift Card (014)
Use the Manage Gift Card request to perform administrative functions on a gift card such as Activate, Deactivate and Reactivate.

Request
The data elements for this request type are as follows:

 

Data Element

Data Type

Length

Description 

C

Amount

integer

8

For Activate, amount is the amount to put on the card. (Not required)
For Deactivate, amount is not required.
For Reactivate, amount to add to the current balance on the            card. (Required)
Processed as implied decimal. $1.25 would be represented as 125.

R

TransactionType

string

10

Identifies the administrative action to take. Can be Activate, Deactivate or Reactivate.

R

PaymentAccountNumber

integer

13-19

Must follow general Credit Card conventions. Supports MC, VI, AX, and DI.

R

AcctType

string

1

Single character, must be set to G

R

ExpirationDate

string

7

Expiration date of the card. If present, the supported format are: MMYY and MM/YY.

R

HolderType

string

1

Single character, either P (Personal account) or O (Organization account).

R

TransIndustryType

string

2

Must match a 2-letter pre-determined industry type. All caps.

Supported values are: RE (Retail), RS (Restaurant), EC (eCommerce), DM (Direct Marketing), LD (Lodging) and CR (Car Rental). HC is also supported for HealthCare, however internally transactions with industry type HC are converted to Retail (RE) transactions.

R

TransactionDate

DateTime

14

Date of the request. Format: yyyyMMddHHmmss

R

MerchantCode

integer

12

The default merchant code assigned to the user.

R

MerchantAccountCode

integer

12

The default merchant account code assigned to the user.

XML Request Layout 

<?xml version="1.0" encoding="utf-16"?>
<requestHeader>
	<ClientIdentifier/>
	<TransactionID/>
	<RequestType>014</RequestType>
	<RequestDateTime/>
	<User/>
	<Password/>
	<requestMessage>
		<TransIndustryType/>
		<TransactionType/>
		<AcctType/>
		<Amount/>
		<ActionType/>
		<PaymentAccountNumber/>
		<ExpirationDate/>
		<HolderType/>
		<MerchantCode/>
		<MerchantAccountCode/>
	</requestMessage>
</requestHeader> 

Response

The response message is included in the Gift element and returns the following data elements:

 

Data Element

Data Type

Length

Description

 

TransactionType

enum

10

Identifies the administrative action taken. Can be Activate, Deactivate or Reactivate.

 

GatewayTransID

integer

 

Identifies the BridgePay Gateway ID number of the request.

 

ResponseType

enum

9

Identifies the type of response received. Can be Good, Soft, Hard or Exception.

 

CashbackAmount

integer

8

Amount of money to be returned to the customer upon deactivation. Provided as implied decimal. $1.25 would be represented as 125.

 

ReferenceNumber

integer

 

Identifies the BridgePay Gateway ID number of the request.

 

ProviderReferenceNumber

string

 

Identifies the reference number of the provider for the request (if any).

 

GatewayResult

string

3

The BridgePay Gateway’s internal code for the result of the request.

 

GatewayMessage

string

 

The BridgePay Gateway’s internal message corresponding to the GatewayResult field.

 

TransactionCode

string

 

Echo back of the TransactionCode used in the request.

 

TransactionDate

DateTime

14

Date of the request. Format: yyyyMMddHHmmss

 

BatchID

integer

8

Identifies the Batch ID this request was allocated to (if any).

XML Response Layout 

<?xml version="1.0" encoding="utf-16"?>
<Gift>
	<TransactionID/>
	<RequestType/>
	<ResponseCode/>
	<ResponseDescription/>
	<responseMessage>
		<GatewayTransID/>
		<GatewayResult/>
		<GatewayMessage/>
		<TransactionCode/>
		<TransactionType/>
		<ResponseType/>
		<CashbackAmount/>
		<ReferenceNumber/>
		<ProviderReferenceNumber/>
		<TransactionDate/>
		<BatchID/>
  </responseMessage>
</Gift>

 


Service Fee

BridgeComm can process a separate service fee transaction for a given principal transaction by providing data about the service fee in the request message. These extra fields are only available on the 004 request type.
The added data elements must be put in a new header elements called <ServiceFee>. See the XML example for more details.

Request

The added data elements for this request type are as follows: 

 

Data Element

Data Type

Length

Description

R

ServiceFeeID

integer

 

A user-defined identifier that will be returned in the response

O

ResellerCode

integer

 

The code of the reseller that owns the service merchant account. Use if not providing service credentials.

R

MerchantCode

integer

 

The code of the merchant that owns the service merchant account. Use if not providing service credentials.

R

MerchantAccountCode

integer

 

The code of the service merchant account. Use if not providing service credentials.

R

Amount

integer

8

The implied decimal implementation of the service fee amount.

R

ServiceUser

string

 

The username associated with the merchant service fee account. Use if not providing ResellerCode, MerchantCode and MerchantAccountCode.

R

ServicePassword

string

 

The password associated with the merchant service fee account. Use if not providing ResellerCode, MerchantCode and MerchantAccountCode.

XML Request Layout 

<?xml version="1.0" encoding="utf-16"?>
<requestHeader>
	<ClientIdentifier/>
	<TransactionID/>
	<RequestType>004</RequestType>
	<RequestDateTime/>
	<User/>
	<Password/>
	<requestMessage>
		...
		<ServiceFee>
			<ServiceFeeID/>
			<ResellerCode/>
			<MerchantCode/>
			<MerchantAccountCode/>
			<Amount/>
			<ServiceUser/>
			<ServicePassword/>
		</ServiceFee>
		...
	</requestMessage>
</requestHeader> 

Response
The Auth response message has been modified to include a <ServiceFeeResult> element. This element contains inner elements describing the results of the service fee transaction. These elements are as follows:

 

Data Element

Data Type

Length

Description

 

ServiceFeeID

integer

 

The user-defined identifier associated with the service fee request

 

AuthorizationCode

string

50

The transaction authorization code returned from the processor.

 

GatewayResult

string

 

5 digit response code for the result of the service fee request

 

AuthorizedAmount

integer

 

Implied decimal representation of the amount that was authorized/charged/refunded.

 

OriginalAmount

integer

 

Implied decimal representation of the amount that was requested to be authorized/charged/refunded.

 

GatewayTransID

integer

 

Transaction ID from the gateway (used as Reference Number for Voids / Refunds).

 

GatewayMessage

string

 

Message from the gateway

 

InternalMessage

string

 

Provides more information from the gateway and processor regarding the results of the transaction request.

XML Response Layout

<?xml version="1.0" encoding="utf-16"?>
<Auth>
	<TransactionID/>
	<RequestType>004</RequestType>
	<ResponseCode>00000</ResponseCode>
	<responseMessage>
		...
		<ServiceFeeResult>
			<ServiceFeeID/>
			<AuthorizationCode/>
			<GatewayResult/>
			<AuthorizedAmount/>
			<OriginalAmount/>
			<GatewayTransID/>
			<GatewayMessage/>
			<InternalMessage/>
		</ServiceFeeResult>
		...
	</responseMessage>
</Auth>

 


Custom Fields

BridgeComm can accept a collection of fields known as custom fields. These extra fields are only available on the 004 request type. They are also available on 012 response if the sale had custom fields. The added data elements must have been put into a new collection element called <CustomFields> and must have been previously created. If the custom field name contains invalid XML characters, the custom field will be rejected, and the response will not include the custom field. Invalid XML characters in the custom field value will be escaped and returned in response. See the XML example for more details.
 

 

Data Element

Data Type

Length

Description

O

CustomFields

collection

n/a

Multiple based on configured custom fields. Please note the custom field elements within the CustomFields collection are case sensitive. They must be presented exactly as they were created.

Below is a working example of how CustomFields are formatted in an actual transaction request and response message. In the example below, a custom field for PATIENT_NAME was previously created for this merchant account.

XML Request Layout

<requestHeader>
	<ClientIdentifier>SOAP</ClientIdentifier>
	<RequestType>004</RequestType>
	<RequestDateTime>20170411121432</RequestDateTime>
	<User>testuser</User>
	<Password>123456</Password>
	<requestMessage>
		<TransIndustryType>RE</TransIndustryType>
		<MerchantCode>0000</MerchantCode>
		<MerchantAccountCode>0001</MerchantAccountCode>
		<Amount>1100</Amount>
		<TransactionType>sale</TransactionType>
		<AcctType>R</AcctType>
		<HolderType>P</HolderType>
		<CustomerWalletID>jr123</CustomerWalletID>
		<CustomFields>
			<PATIENT_NAME>BOB JONES</PATIENT_NAME>
		</CustomFields>
	</requestMessage>
</requestHeader> 

XML Response Layout

<Auth>
	<RequestType>004</RequestType>
	<ResponseCode>00000</ResponseCode>
	<ResponseDescription>Successful Request</ResponseDescription>
	<responseMessage>
		<Token>1000000010261111</Token>
		<ExpirationDate>1022</ExpirationDate>
		<AuthorizationCode>TAS161</AuthorizationCode>
		<ReferenceNumber>904513501564</ReferenceNumber>
		<AuthorizedAmount>1100</AuthorizedAmount>
		<OriginalAmount>1100</OriginalAmount>
		<GatewayTransID>44915101</GatewayTransID>
		<GatewayMessage>A01 - Approved (NO MATCH)</GatewayMessage>
		<InternalMessage>Approved: TAS161 (approval code)</InternalMessage>
		<GatewayResult>00000</GatewayResult>
		<AVSMessage>Street address and ZIP don't match</AVSMessage>
		<AVSResult>45</AVSResult>
		<CVMessage/>
		<CVResult/>
		<TransactionCode/>
		<TransactionDate>20190214</TransactionDate>
		<RemainingAmount>0</RemainingAmount>
		<IsoCountryCode>840</IsoCountryCode>
		<IsoCurrencyCode>USD</IsoCurrencyCode>
		<IsoTransactionDate>2019-02-14 08:54:15.893</IsoTransactionDate>
		<IsoRequestDate>2019-02-14 08:54:15.893</IsoRequestDate>
		<NetworkReferenceNumber>904513501564</NetworkReferenceNumber>
		<MerchantCategoryCode>5999</MerchantCategoryCode>
		<NetworkMerchantId>888000000841</NetworkMerchantId>
		<NetworkTerminalId>1515</NetworkTerminalId>
		<CardClass>Credit</CardClass>
		<CardType>Visa</CardType>
		<CardHolderName>Faucette Leaky</CardHolderName>
		<CardModifier>None</CardModifier>
		<ProviderResponseCode>00</ProviderResponseCode>
		<ProviderResponseMessage> NO MATCH </ProviderResponseMessage>
		<MaskedPan/>
		<ResponseTypeDescription>sale</ResponseTypeDescription>
		<IsCommercialCard>False</IsCommercialCard>
		<StreetMatchMessage/>
		<WalletID/>
		<WalletPaymentMethodID/>
		<WalletResponseCode/>
		<WalletResponseMessage/>
	</responseMessage>
</Auth> 

 


Card on File

The following information describes how to interact with the BridgePay system for Card on File, also known as Credential on File or Stored Credentials, for Customer Initiated Transactions (CIT) and Merchant Initiated Transactions (MIT). These guidelines are applicable to situations where a merchant intends to store the payment information of the cardholder in order to process future transactions. Storage of payment information can be defined as storing the credit card number/debit card number/ACH account number or equivalent gateway token or wallet.

Card on File revolves around two fundamental concepts:1. Scheduled Payment versus Unscheduled Payment

  1. Customer Initiated Transaction versus Merchant Initiated Transaction

Scheduled Payment versus Unscheduled Payment 
Scheduled Payment means the merchant knows when the cardholder’s payment information will be used to process a payment on their behalf. In order for this to take place the merchant is required to get permission from the cardholder to store the payment information for later use before processing a scheduled payment. The two types of scheduled payments are Recurring and Installment.

An Unscheduled Payment is any payment that is not part of a recurring or installment plan.

Customer Initiated Transaction versus Merchant Initiated Transaction
A Customer Initiated Transaction is one whereby the cardholder is directly interacting with a checkout process, whether that is in-person or on-line. Within a customer initiated transaction a merchant can ask for permission to store the payment information for later use.

A Merchant Initiated Transaction is one whereby the cardholder is not an active participant in the payment and the merchant is running a payment using stored information previously approved by the cardholder.

Prior to a Merchant Initiated Transaction a Customer Initiated Transaction must have been performed.

Customer Initiated Transactions can be classified as Initial Unscheduled, Initial Installment or Initial Recurring or Unscheduled Customer.

Storing the Card On File
In order to store the card on file, the cardholder must give permission to have their payment information stored for later use. Once permission is granted the merchant needs to perform a transaction to the gateway setting the StoredCredential field to the appropriate value in order to initiate the card on file event with the card issuer. This can be done via processing a 004 account-verification, sale or sale-auth and setting the StoredCredential field to one of the following values:

InitialUnscheduled – customer initiated transaction where the cardholder’s payment information will be stored for later use not in association with an installment or recurring plan.

InitialInstallment – customer initiated transaction where the cardholder’s payment information will be stored for later use in association with an installment payment plan.

InitialRecurring – customer initiated transaction where the cardholder’s payment information will be stored for later use in association with a recurring payment plan.

In response the merchant’s system will receive the NetworkReferenceNumber in the BridgeComm response. Future installment or recurring payments for this card on file must include the NetworkReferenceNumber value.

Processing Payments with the Card On File
In order to process payments using the card on file, the merchant will send 004 sale or sale-auth transactions using the following StoredCredential values as appropriate. If the payment is for Installment or Recurring then the NetworkReferenceNumber received on the Initial card on file creation event must also be supplied.

UnscheduledMerchant - Merchant initiated transaction for any scenario where the cardholder has given consent for a payment to be processed using their card on file that is not associated with an installment or recurring payment plan.

Installment – Merchant initiated transaction related to an installment plan which consists of an agreement between the merchant and cardholder to process one or more payment(s) over a duration of time for a single good or service.

Recurring – Merchant initiated transaction related to a recurring payment plan which consists of an agreement between the merchant and cardholder to process a recurring payment over a duration of time at a regular interval for a good or a service.

API Basics:
 

Required

Data Element

Data Type

Length

Description

O

StoredCredential

String

30

Identifies the type of card on file action taking place. Valid Values are:

  • Storing the Card/Credential for the first time:

    •  InitialUnscheduled - Indicates that a card is being stored for the first time not in
      association with a recurring or installment plan.

    • InitialInstallment - Indicates that a card is being stored for the first time in
      association with an installment plan.

    • InitialRecurring - Indicates that a card is being stored for the first time in association
      with a recurring plan.

  • Using the Card On File (a previously stored credential):

    • UnscheduledCustomer - Customer initiated transaction, whether in-person or
      on-line; that is not part of a recurring or installment plan.

    • UnscheduledMerchant - Merchant initiated transaction that is not part of a recurring
      or installment plan.

    • Installment - processing a payment on an installment payment plan using a card on
      file.

    • Recurring - processing a payment on a recurring payment plan using a card on file.

O

NetworkReferenceNumber

String

30

The "NetworkReferenceNumber" is a response field used in Recurring and Installment transactions
when the "StoredCredential" element is passed with the Initial or Recurring payment request. The
returned "NetworkReferenceNumber" value must also be passed in every subsequent Recurring or
Installment transaction in the payment series. The updated (new) value returned from the previous
(or last) transaction processed must then be submitted with the next transaction in the payment
series, and so forth.  

Note: This is required for all Card Token Sales. 


Version Reporting

The BridgeComm API provides a request to check the current version. This request does not require Base64 encoding.

UAT:
https://www.bridgepaynetsecuretest.com/PaymentService/VersionReporter.svc

PROD:
https://www.bridgepaynetsecuretx.com/PaymentService/VersionReporter.svc

Request headers should be set to the following:

 

Request:

<Envelope xmlns="https://schemas.xmlsoap.org/soap/envelope/">
	<Body>
		<GetVersion xmlns="http://bridgepaynetsecuretx.com/versionreporter"/>
		<Body>
</Envelope> 

Response:

<s:Envelope xmlns:s="https://schemas.xmlsoap.org/soap/envelope/">
	<s:Body>
		<GetVersionResponse xmlns="https://bridgepaynetsuretx.com/versionreporter">
			<GetVersionResult xmlns:a="https://schemas.datacontract.org/2004/07/Bridgepay.Core.Models" xmlns:i="https://www.w3.org/2001/XMLSchema-instance">
				<a:ApplicationName>Bridgepay.Communication.Sevice</a:ApplicationName>
				<a:VersionNumber>2022.2.99</a:VersionNumber>
			</GetVersionResult>
		</GetVersionResponse>
	</s:Body>
</s:Envelope> 

  • No labels