- Created by Mark Mauer, last modified by Danna Larson on Jul 12, 2023
You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 44 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) | This access method accepts a base64 encoded XML formatted request message and returns a base64 encoded XML formatted response. |
string ProcessMessage | 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) | 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 |
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) | 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 |
|
|
|
Process Payment | 004 |
|
|
|
Is Debit (BIN lookup) | 005 |
|
|
|
Change Password | 007 |
|
|
|
Get Merchant Data | 011 |
|
|
|
Void/Refund | 012 |
|
|
|
Tokenize Account | 013 |
|
|
|
Manage Gift Card | 014 |
|
|
|
Capture | 019 |
|
|
|
Initiate Settlement | 020 |
|
|
|
Ping | 099 |
|
|
|
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 Integration 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:
|
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:
|
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. |
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’ |
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 |
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. |
| 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 |
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 |
C | RoomRateAmount | integer | 8 | Daily room rate. Implied decimal. |
O | RoomTaxAmount | integer | 8 | Tax charged on daily rate. Implied decimal. |
R | LodgingChargeType | Enum |
| Type of service for which this transaction is processed.
|
C | CheckInDate | Date |
| The date of actual or anticipated check-in. |
C | CheckOutDate | Date |
| The date of actual or anticipated check-out |
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.
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. |
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
|
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. |
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
|
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
Merchant calls AcquirePurchaseToken
AcquirePurchaseToken("user","password","",500,"12345","98765")
Merchant receives Purchase Token
returnValue = “0E0D6C55-AF5E-49AE-8DE7-001B08A550CF”
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<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<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) |
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
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:
|
O | NetworkReferenceNumber | String | 30 | The "NetworkReferenceNumber" is a response field used in Recurring and Installment transactions 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:
Content-Type = text/xml;charset=UTF-8
SOAPAction = "http://bridgepaynetsecuretx.com/versionreporter/IVersionReporter/GetVersion"
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