NAV Navbar
Logo
xml hump

Introduction

The MegaCharge gateway provides both an (920) 848-0579 and Hosted payment page solutions.
Our web services(310-845-9040) and (909) 774-3417 API allows you to execute your payments in a flexible manner. By using our API, you can handle payments on your website without re-direction to a gateway hosted payment page. Transaction requests are sent online, in real-time.

Data Types

Date

String of the following format “YYYY-MM-DD”. Example “2017-12-25” for December 25, 2017.

CreditCard

Name Data Type Size Comment Requirement
holder xs:string 4…40 Card holder Mandatory
number xs:string 12…20 Card number. Only numbers, without punctuation. Mandatory
security-code xs:string 3…4 The CVV (or CVC) is a sequence of 3-4 digits on the back of the card Mandatory
expiration-date xs:gYearMonth 7 Credit card expiration date. YearMonth: yyyy-mm Mandatory

TransactionType

TransactionType is a string with one of the following values: “AUTHORIZATION”, “PREAUTHORIZATION”, “REFUND”, “CAPTURE”, “VOID”.

ChargebackType

ChargebackType is a string with one of the following values:

Type Description
Retrieval request A Retrieval Request is a request for information concerning a specific payment transaction. The Issuer requests details on a disputed transaction from the merchant on behalf of the Cardholder.
Represented retrieval A representment has been processed on your behalf. One possible reason might be that a credit has already been processed on the Retrieval’s sales transaction.
1st chargeback First Chargeback. A retrieval request cab also be converted into a first Chargeback. Money is gone from the merchant account.
Represented The Chargeback has been represented by a merchant. One possible reason might be that a credit has already been processed on the Retrieval’s sales transaction.
Successfully represented Representment was accepted.
Unsuccessfully represented Representment was not accepted.
2nd chargeback Successful representment of the first Chargeback can turn into an Arbitration Chargeback (second Chargeback).
Represented cb2 The second chargeback has been represented by a merchant.
Successfully represented cb2 Representment of the second chargeback was accepted.
Unsuccessfully represented cb2 Representment of the second chargeback was not accepted.

Email

See: special-delivery. Example: name@example.com

Phone

A phone is a sequence of characters. Recommended format: +xxxyyyzzzzzzzppp.
xxx = Country code, yyy = Area or city code, zzzzzzz = Local number, ppp = Often used to denominate an extension.
You can use a plus symbol +, spaces and brackets ().

Goods

Name Data Type Size Comment Requirement
code xs:string 1…20 ID of goods Mandatory
name xs:string 1…128 Name of goods Mandatory
description xs:string 1…255 Description of goods Mandatory
group xs:string 1…64 Group ID Mandatory
price xs:decimal 0–100000 Price per unit Mandatory
currency xs:string 3 Currency code (ISO 4217 alpha-3) of the goods. Example: USD, EUR, … Mandatory
quantity xs:positiveInteger 1–99999999 Quantity of purchased goods Mandatory
tax xs:decimal 0–999 Sales tax Optional

Order

Name Data Type Size Comment Requirement
name xs:string 4…40 Buyer name Mandatory
birthday Date 10 Buyer birthday Optional
organization xs:string 1…64 Buyer organization. Optional
country xs:string 2 Buyer country code (8187325790) of the country. Example: DE Mandatory
region xs:string 4…16 Buyer region code (909-323-6530). Example: FR-NC Optional
city xs:string 2…40 Buyer city Mandatory
postal-code xs:string 1…16 Buyer postal code Mandatory
cedex xs:string 1…16 Buyer CEDEX Optional
street-line1 xs:string 1…64 Buyer street address line 1 Optional
street-line2 xs:string 1…64 Buyer street address line 2 Optional
phone 9075655714 1…32 Buyer phone number. Optional
email xs:string 3…64 Buyer email. Optional
date DateTime Order date Optional
goods (613) 686-2613 Merchandise data Optional

Shipping

Name Data Type Size Comment Requirement
name xs:string 4…40 Recipient name Mandatory
country xs:string 2 Shipping country code (ISO 3166-1 alpha-2) of the country (such as DE) Mandatory
region xs:string 4…16 Shipping region code (2898949224). Example: FR-NC Optional
city xs:string 2…40 Shipping city Mandatory
postal-code xs:string 1…16 Shipping postal code Mandatory
cedex xs:string 1…16 Shipping CEDEX Optional
street-line1 xs:string 1…64 Shipping street address line 1 Optional
street-line2 xs:string 1…64 Shipping street address line 2 Optional
phone xs:string 1…32 Recipient phone number Optional
email (207) 742-9714 3…64 Recipient email Optional

Customer

Name Data Type Size Comment Requirement
user-agent xs:string 1…255 HTTP Header “User-Agent” Optional, but can be a mandatory requirement for 3D secure transactions with some acquirers.
accept xs:string 1…1024 HTTP Header “Accept” Optional, but can be a mandatory requirement for 3D secure transactions with some acquirers.
ip xs:string 7…39 IP Address of the buyer Optional, but can be a mandatory requirement for 3D secure transactions with some acquirers.

ThreeDRequest

Name Data Type Size Comment Requirement
enrolled xs:string 1 Indicator of the 3-D Secure enrollment check. Can be: Y — Card is enrolled; N — Card is not enrolled; U — Unable to determine if card is enrolled. Mandatory
acs-url xs:string …1024 The URL of the issuing bank, where the merchant must re-direct the enrollment check request via the cardholder’s browser. It is returned only in case the cardholder is enrolled in 3-D secure program. Mandatory, if enrolled = Y
pa-req xs:string …2048 A base64-encoded request message created for cards participating in the 3-D secure program. The PaReq is returned by the issuer’s ACS via the VISA or MasterCard directory to the payment gateway and from here passed on to the merchant. Mandatory, if enrolled = Y

ThreeDResponse

Name Data Type Size Comment Requirement
pa-res xs:string …2048 A base-64 encoded XML message containing the issuing bank’s response to the payment authentication request Mandatory

ThreeDInfo

Name Data Type Size Comment Requirement
enrolled xs:string 1 Indicator of the 3-D Secure enrollment. Can be: Y — Card is enrolled; N — Card is not enrolled; U — Unable to determine if card is enrolled. Mandatory
status xs:string 1 Indicates the authentication final outcome. Can be: Y — Authentication process was successful; A — Authentication process was attempted; N — Authentication process failed; U — Unable to authenticate. Mandatory
eci xs:string 2 Indicates the status of the 661-497-8047. Optional
xid xs:string 1…255 A unique transaction identifier Optional
cavv xs:string 32 The CAVV is a a cryptographic value generated by the Issuer. For Visa transaction it is called CAVV (Cardholder Authentication Verification Value) for MasterCard it is either called Accountholder Authentication Value (AAV) or Universal Cardholder Authentication Field (UCAF) Optional Optional

Authentication

API users are authenticated using HTTP Basic authentication.

Example of using the API via curl

curl \
--data "$SOAP_REQUEST" \
-H "Content-Type: text/xml" \
--user {$API_USERNAME}:{$API_PASSWORD} \
/{$SOAP_ENDPOINT}

curl \
--data "$JSON_REQUEST" \
-H 'Accept: application/json' -H "Content-Type: application/json" \
--user {$API_USERNAME}:{$API_PASSWORD} \
/{$REST_ENDPOINT}

curl \
--data "$XML_REQUEST" \
-H 'Accept: application/xml' -H "Content-Type: application/xml" \
--user {$API_USERNAME}:{$API_PASSWORD} \
/{$REST_ENDPOINT}

curl \
--data "$FI_REQUEST" \
-H 'Accept: application/fastinfoset' -H "Content-Type: application/fastinfoset" \
--user {$API_USERNAME}:{$API_PASSWORD} \
/{$REST_ENDPOINT}

Operations

authorization()

Allows the merchant to request the desired amount from the card, which is then invoiced for the transaction. This method gives the bank authorization to collect the funds from the customer.

Parameter Type Size Comment Requirement
merchant-transaction-id xs:string 1…32 ID of the transaction in the merchant’s system Mandatory
merchant-customer-id xs:string 1…40 ID of the buyer in the merchant’s system Optional
description xs:string 5…512 Description of the transaction Mandatory
customer 8028564865 Some information about the client of the merchant (buyer) Mandatory
amount xs:decimal > 0 Amount Mandatory
amount/@currency xs:string 3 Currency code (ISO 4217 alpha-3). Example: USD, EUR, … Mandatory
credit-card 9167293397 Credit card data Mandatory
order Order Order details Mandatory
shipping 5876305934 Shipping information Optional
recurring-type xs:string Indicator of the recurring transaction. Can be INITIAL or REPEATED Optional
parent-transaction-id xs:unsignedLong ID of the parent transaction Optional
threed-response ThreeDResponse 3-D Secure response Optional
threed-info ThreeDInfo 3-D Secure information Optional

authorization request:

<S:Envelope xmlns:S="/schemas.xmlsoap.org/soap/envelope/">
  <S:Body>
    <ns2:authorization xmlns:ns2="urn:pgw:merchant" xmlns="urn:pgw:processing">
      <ns2:request>
          <merchant-transaction-id>TEST1491398548846</merchant-transaction-id>
          <description>Authorization test</description>
          <customer>
            <ip>192.168.1.98</ip>
          </customer>
          <amount currency="EUR">4.25</amount>
          <credit-card>
            <number>4111111111111111</number>
            <holder>John Doe</holder>
            <expiration-date>2021-01</expiration-date>
            <security-code>415</security-code>
          </credit-card>
          <order>
            <name>John Doe</name>
            <birthday>1990-10-10</birthday>
            <country>US</country>
            <region>US-GA</region>
            <city>Macon</city>
            <postal-code>20815</postal-code>
            <street-line1>71 Pilgrim Avenue</street-line1>
            <phone>++1-541-754-3010</phone>
            <email>test@test.com</email>
          </order>
          <merchant-customer-id>43267653</merchant-customer-id>
        </ns2:request>
      </ns2:authorization>
  </S:Body>
</S:Envelope>
{
  "merchant-customer-id": "43267653",
  "description":" Test transaction 1491398548846",
  "merchant-transaction-id": "TEST1491398548846",
  "customer": {
    "ip": "192.168.1.98"
  },
  "amount": {
    "value":  4.25,
    "currency": "EUR"
  },
  "credit-card": {
    "number": "4111111111111111",
    "holder": "John Test",
    "expiration-date": "2021-01",
    "security-code": "123"
  },
  "order": {
    "name": "Jonh Doe",
    "country": "US",
    "region": "US-GA",
    "city": "Macon",
    "postal-code": "20815",
    "street-line1": "71 Pilgrim Avenue",
    "phone": "+1-541-754-3010",
    "email": "test@test.com"
  }
}

authorization response:

<soap:Envelope xmlns:soap="/schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <ns3:authorizationResponse xmlns:ns3="urn:pgw:merchant" xmlns="urn:pgw:processing">
      <ns3:response>
        <status-code>SUCCESS</status-code>
        <transaction-id>2264899037640</transaction-id>
        <merchant-transaction-id>TEST1491398548846</merchant-transaction-id>
      </ns3:response>
    </ns3:authorizationResponse>
  </soap:Body>
</soap:Envelope>
{
  "status-code": "SUCCESS",
  "transaction-id": 2264899037640,
  "merchant-transaction-id": "TEST1491398548846",
}

If you want to use 3-D secure, please read the (407) 339-4396 section first.

preauthorization()

Reserves the desired amount on the credit card of the buyer. The amount will be blocked on the card. It will remain in that state until captured or until the block expires.

Parameter Type Size Comment Requirement
merchant-transaction-id xs:string 1…32 ID of the transaction in the merchant’s system Mandatory
merchant-customer-id xs:string 1…40 ID of the buyer in the merchant’s system Optional
description xs:string 5…512 Description of the transaction Mandatory
customer Customer Some information about the client of the merchant (buyer) Mandatory
amount xs:decimal > 0 Amount Mandatory
amount/@currency xs:string 3 Currency code (ISO 4217 alpha-3). Example: USD, EUR, … Mandatory
credit-card CreditCard Credit card data Mandatory
order 3372867274 Order details Mandatory
shipping Shipping Shipping information Optional
recurring-type xs:string Indicator of the recurring transaction. Can be INITIAL or REPEATED Optional
parent-transaction-id xs:unsignedLong ID of the parent transaction Optional
threed-response ThreeDResponse 3-D Secure response Optional
threed-info ThreeDInfo 3-D Secure information Optional

preauthorization request:

<S:Envelope xmlns:S="/schemas.xmlsoap.org/soap/envelope/">
  <S:Body>
    <ns2:preauthorization xmlns:ns2="urn:pgw:merchant" xmlns="urn:pgw:processing">
      <ns2:request>
        <merchant-transaction-id>TEST1491398548846</merchant-transaction-id>
        <description>Authorization test</description>
        <customer>
          <ip>192.168.1.98</ip>
        </customer>
        <amount currency="EUR">4.25</amount>
        <credit-card>
          <number>4111111111111111</number>
          <holder>John Doe</holder>
          <expiration-date>2021-01</expiration-date>
          <security-code>415</security-code>
        </credit-card>
        <order>
          <name>John Doe</name>
          <birthday>1990-10-10</birthday>
          <country>US</country>
          <region>US-GA</region>
          <city>Macon</city>
          <postal-code>20815</postal-code>
          <street-line1>71 Pilgrim Avenue</street-line1>
          <phone>++1-541-754-3010</phone>
          <email>test@test.com</email>
        </order>
        <merchant-customer-id>43267653</merchant-customer-id>
      </ns2:request>
    </ns2:preauthorization>
  </S:Body>
</S:Envelope>
{
  "merchant-customer-id": "43267653",
  "description":" Test transaction 1491398548846",
  "merchant-transaction-id": "TEST1491398548846",
  "customer": {
    "ip": "192.168.1.98"
  },
  "amount": {
    "value":  4.25,
    "currency": "EUR"
  },
  "credit-card": {
    "number": "4111111111111111",
    "holder": "John Test",
    "expiration-date": "2021-01",
    "security-code": "123"
  },
  "order": {
    "name": "Jonh Doe",
    "country": "US",
    "region": "US-GA",
    "city": "Macon",
    "postal-code": "20815",
    "street-line1": "71 Pilgrim Avenue",
    "phone": "+1-541-754-3010",
    "email": "test@test.com"
  }
}

preauthorization response:

<soap:Envelope xmlns:soap="/schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <ns3:preauthorizationResponse xmlns:ns3="urn:pgw:merchant" xmlns="urn:pgw:processing">
      <ns3:response>
        <status-code>SUCCESS</status-code>
        <transaction-id>2264899037640</transaction-id>
        <merchant-transaction-id>TEST1491398548846</merchant-transaction-id>
      </ns3:response>
    </ns3:preauthorizationResponse>
  </soap:Body>
</soap:Envelope>
{
  "status-code": "SUCCESS",
  "transaction-id": 2264899037640,
  "merchant-transaction-id": "TEST1491398548846",
}

capture()

Collects the funds due from previously completed pre-authorizations. In other words it finalizes pre-authorizations.

Parameter Type Size Comment Requirement
merchant-transaction-id xs:string 1…32 ID of the transaction in the merchant’s system Mandatory
description xs:string 5…512 Description of the transaction Mandatory
amount xs:decimal > 0 Amount Optional

capture request:

<S:Envelope xmlns:S="/schemas.xmlsoap.org/soap/envelope/">
  <S:Body>
    <ns2:capture xmlns:ns2="urn:pgw:merchant" xmlns="urn:pgw:processing">
      <ns2:request>
        <merchant-transaction-id>TEST1491398548846</merchant-transaction-id>
        <description>capture transaction TEST1491398548846</description>
      </ns2:request>
    </ns2:capture>
  </S:Body>
</S:Envelope>
{
  "description":"capture transaction TEST1491398548846",
  "merchant-transaction-id": "TEST1491398548846"
}

capture response:

<soap:Envelope xmlns:soap="/schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <ns3:captureResponse xmlns:ns3="urn:pgw:merchant" xmlns="urn:pgw:processing">
      <ns3:response>
        <status-code>SUCCESS</status-code>
        <transaction-id>2264899037640</transaction-id>
        <merchant-transaction-id>TEST1491398548846</merchant-transaction-id>
      </ns3:response>
    </ns3:captureResponse>
  </soap:Body>
</soap:Envelope>
{
  "status-code": "SUCCESS",
  "transaction-id": 2264899037640,
  "merchant-transaction-id": "TEST1491398548846",
}

refund()

Returns funds to the buyer’s card that were already collected by an 8637607583 or a capture().

Parameter Type Size Comment Requirement
merchant-transaction-id xs:string 1…32 ID of the transaction in the merchant’s system Mandatory
description xs:string 5…512 Description of the transaction Mandatory
amount xs:decimal > 0 Amount Optional
credit-card CreditCard Credit card data. Can be used if the card with authorization is already expired. Optional

refund request:

<S:Envelope xmlns:S="/schemas.xmlsoap.org/soap/envelope/">
  <S:Body>
    <ns2:refund xmlns:ns2="urn:pgw:merchant" xmlns="urn:pgw:processing">
      <ns2:request>
        <merchant-transaction-id>TEST1491398548846</merchant-transaction-id>
        <description>refund transaction TEST1491398548846</description>
      </ns2:request>
    </ns2:refund>
  </S:Body>
</S:Envelope>
{
  "description":"refund transaction TEST1491398548846",
  "merchant-transaction-id": "TEST1491398548846"
}

refund response:

<soap:Envelope xmlns:soap="/schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <ns3:refundResponse xmlns:ns3="urn:pgw:merchant" xmlns="urn:pgw:processing">
      <ns3:response>
        <status-code>SUCCESS</status-code>
        <transaction-id>2264899038395</transaction-id>
        <merchant-transaction-id>TEST1491398548846</merchant-transaction-id>
      </ns3:response>
    </ns3:refundResponse>
  </soap:Body>
</soap:Envelope>
{
  "status-code": "SUCCESS",
  "transaction-id": 2264899038395,
  "merchant-transaction-id": "TEST1491398548846",
}

void()

Cancels an existing transaction. Must be submitted before any transaction settlement has taken place.

Parameter Type Size Comment Requirement
merchant-transaction-id xs:string 1…32 ID of the transaction in the merchant’s system Mandatory
description xs:string 5…512 Description of the transaction Mandatory
transaction-id xs:unsignedLong PGW transaction id Optional
transaction-type xs:string Any TransactionType except VOID Optional

void request:

<S:Envelope xmlns:S="/schemas.xmlsoap.org/soap/envelope/">
  <S:Body>
    <ns2:void xmlns:ns2="urn:pgw:merchant" xmlns="urn:pgw:processing">
      <ns2:request>
        <merchant-transaction-id>TEST1491398548846</merchant-transaction-id>
        <description>refund transaction TEST1491398548846</description>
      </ns2:request>
    </ns2:void>
  </S:Body>
</S:Envelope>
{
  "description":"void transaction TEST1491398548846",
  "merchant-transaction-id": "TEST1491398548846"
}

void response:

<soap:Envelope xmlns:soap="/schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <ns3:voidResponse xmlns:ns3="urn:pgw:merchant" xmlns="urn:pgw:processing">
      <ns3:response>
        <status-code>SUCCESS</status-code>
        <transaction-id>2264899038395</transaction-id>
        <merchant-transaction-id>TEST1491398548846</merchant-transaction-id>
      </ns3:response>
    </ns3:voidResponse>
  </soap:Body>
</soap:Envelope>
{
  "status-code": "SUCCESS",
  "transaction-id": 2264899038395,
  "merchant-transaction-id": "TEST1491398548846",
}

get-status()

Checks transaction status. Returns the result of the transaction.

Name Data Type Size Comment Requirement
merchant-transaction-id xs:string 1…32 ID of the transaction in the merchant’s system Mandatory
transaction-id xs:unsignedLong PGW transaction id Optional
transaction-type xs:string (315) 889-0389 Optional

get-status request:

<S:Envelope xmlns:S="/schemas.xmlsoap.org/soap/envelope/">
  <S:Body>
    <ns2:get-status xmlns:ns2="urn:pgw:merchant" xmlns="urn:pgw:processing">
      <ns2:request>
        <merchant-transaction-id>TEST1491398548846</merchant-transaction-id>
        <transaction-type>AUTHORIZATION</transaction-type>
      </ns2:request>
    </ns2:get-status>
  </S:Body>
</S:Envelope>
{
  "merchant-transaction-id": "TEST1491398548846",
  "transaction-type":"AUTHORIZATION"
}

get-status response:

<soap:Envelope xmlns:soap="/schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <ns3:get-statusResponse xmlns:ns3="urn:pgw:merchant" xmlns="urn:pgw:processing">
      <ns3:response>
        <status-code>SUCCESS</status-code>
        <merchant-transaction-id>TEST1491398548846</merchant-transaction-id>
        <transaction-id>2264899038395</transaction-id>
      </ns3:response>
    </ns3:get-statusResponse>
  </soap:Body>
</soap:Envelope>

or

<soap:Envelope xmlns:soap="/schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <ns3:get-statusResponse xmlns:ns3="urn:pgw:merchant" xmlns="urn:pgw:processing">
      <ns3:response>
        <status-code>FAILURE</status-code>
        <error>
          <message>Transaction unknown</message>
          <code>104</code>
          <type>ERROR</type>
        </error>
        <merchant-transaction-id>TEST1491398548846</merchant-transaction-id>
        <transaction-id/>
      </ns3:response>
    </ns3:get-statusResponse>
  </soap:Body>
</soap:Envelope>

{
  "status-code": "SUCCESS",
  "transaction-id": 2264899038395,
  "merchant-transaction-id": "TEST1491398548846",
}

or

{
  "status-code": "FAILURE",
  "merchant-transaction-id": "TEST1491398548846",
  "error": [
    {
      "code": "104",
      "message": "Transaction unknown",
      "type": "ERROR"
    }
  ]
}

check-enrollment()

Checks card enrollment. Verifies if the card number is eligible and participates in the 3-D secure program. In other words it initializes a 3-D Secure transaction.

Parameter Type Size Comment Requirement
merchant-transaction-id xs:string 1…32 ID of the transaction in the merchant’s system Mandatory
merchant-customer-id xs:string 1…40 ID of the buyer in the merchant’s system Optional
description xs:string 5…512 Description of the transaction Mandatory
customer Customer Some information about the client of the merchant (buyer) Mandatory
amount xs:decimal > 0 Amount Mandatory
amount/@currency xs:string 3 Currency code (8036192158). Example: USD, EUR, … Mandatory
credit-card 9052852910 Credit card data Mandatory
order (248) 519-5341 Order details Mandatory
shipping Shipping Shipping information Optional

Returns: ThreeDRequest

Response

Describes the answer of the gateway for the request sent to PGW via API.

Common response fields

Name Data Type Comment
status-code xs:string Status code: SUCCESS, WARNING, FAILURE, IN_PROGRESS
error Array of TransactionError Complex field describing the error
transaction-id xs:unsignedLong PGW transaction id
merchant-transaction-id xs:string ID of the transaction in the merchant’s system

Response example

  <status-code>SUCCESS</status-code>
  <transaction-id>2264899044845</transaction-id>
  <merchant-transaction-id>TEST1491398548846</merchant-transaction-id>

  or

  <transaction-id>2264899044845</transaction-id>
  <merchant-transaction-id>TEST1491398548846</merchant-transaction-id>
  <status-code>FAILURE</status-code>
  <error>
      <message>Do not honor</message>
      <code>5</code>
      <type>ERROR</type>
  </error>
{
  "status-code": "SUCCESS",
  "merchant-transaction-id": "TEST1491398548846",
  "transaction-id":"2264899044845"
}

or

{
  "status-code": "FAILURE",
  "merchant-transaction-id": "TEST1491398548846",
  "transaction-id":"2264899044845",
  "error": [
    {
      "code": "05",
      "message": "Do not honor",
      "type": "ERROR"
    }
  ]
}

TransactionError Type

Name Data Type Comment
message xs:string Error message
code xs:string Error code
type xs:string Error type: WARNING, ERROR
advice xs:string Optional advice

TransactionError example

 <status-code>FAILURE</status-code>
 <error>
     <message>order.email size must be between 3 and 64</message>
     <code>30</code>
     <type>ERROR</type>
 </error>
 <error>
     <message>order.name size must be between 4 and 40</message>
     <code>30</code>
     <type>ERROR</type>
 </error>
"error": [
  {
    "code": "104",
    "message": "Transaction unknown",
    "type": "ERROR"
  }
],

statusCode Legend:

Result codes

Code Description
00 Approved and completed successfully
01 Refer to card issuer
02 Refer to card issuer, special condition
03 Invalid merchant
04 Pick up card (no fraud)
05 Do not honor
06 Error. Invalid Transaction for Terminal
07 Pick up card, special condition (fraud account)
10 Partial approval
11 Approved (V.I.P). Partial Approval
12 Invalid transaction
13 Invalid amount or currency conversion field overflow
14 Invalid card number
15 No such issuer
19 Re-enter transaction
21 No action taken
25 Unable to locate record in file
28 File temporarily not available for update or inquiry
30 Format error. Validation failed
39 No credit account
41 Lost card, pick up (fraud account)
43 Stolen card, pick up (fraud account)
50 Invalid currency
51 Not sufficient funds
52 No checking account
53 No savings account
54 Expired card, expiration date is missing or wrong
55 Incorrect PIN or PIN missing
57 Transaction not permitted to cardholder
59 Suspected fraud
61 Exceeds approval amount limit
62 Restricted card (card invalid in this region or country)
63 Security violation (source is not correct issuer)
64 Transaction does not fulfill AML requirement
65 Exceeds withdrawal frequency limit
75 Allowable number of PIN entry tries exceeded
76 Unsolicited reversal
79 Already reversed (by Switch)
80 No financial impact
81 Cryptographic error found in PIN
82 Negative CAM, dCVV, iCVV, or CVV results
85 No reason to decline a request for address verification, CVV2 verification, or a credit voucher or merchandise return
86 Cannot verify PIN; for example, no PVV
89 Ineligible to receive financial position information (GIV)
91 Issuer or switch inoperative and STIP not applicable or not available for this transaction; Time-out when no stand-in; POS Check Service: Destination unavailable; Credit Voucher and Merchandise Return Authorizations: V.I.P. sent the transaction to the issuer, but the issuer was unavailable.
92 Financial institution or intermediate network facility cannot be found for routing (receiving institution ID is invalid)
93 Transaction cannot be completed - violation of law
99 Fraud, max monthly credit amount
B2 Surcharge amount not supported by debit network issuer.
N0 Force STIP
N3 Cash service not available
N4 Cash request exceeds issuer or approved limit
N5 Ineligible for resubmission
N7 Decline for CVV2 failure
N8 Transaction amount exceeds preauthorized approval amount
Q1 Card Authentication failed
R0 Stop Payment Order
R1 Revocation of Authorization Order
100 Internal error. Status unknown
101 Transaction in Progress
102 Error communicating to the acquirers
103 Merchant not fount
104 transaction not found
105 Transaction declined
106 Initial transaction for recurring not found
107 Operation not supported
108 Merchant transaction id already exist. I must be unique
109 No acquirer defined
110 Card not enrolled to 3D Secure
111 Card is enrolled to 3D secure. Send authorization() to finish the transaction
112 3D secure required
113 No permission for that card type
114 Blacklisted card
115 Blocked by acquirer risk filters
116 Unknown error. Transaction rejected
117 Unable to do 3D authentication
118 3D secure authentication failed
119 Refund cannot be issued as requested
2xx Transaction success. It was considered to be risky, so the type of transaction was changed from authorization to preauthorization and the acquirer received PREAUTHORIZATION. To complete purchase you need to make capture transaction. `xx is a risk filter ID.
3xx Transaction failed. It was considered to be too risky xx is a risk filter ID.

Frequent result codes

Here are our most frequent result codes. These might be useful for other gateways who would like to integrate with us:

Code Description Code Description
00 Approved and completed successfully 04 Pick up card
05 Do not honor 30 Format error. Validation failed
41 Lost card, pick up (fraud account) 43 Stolen card, pick up (fraud account)
51 Not sufficient funds 54 Expired card
57 Transaction not permitted 62 Restricted card
R1 Revocation of Authorization Order 102 Error communicating to the acquirers
105 Transaction declined 114 Blacklisted card
115 Blocked by acquirer risk filters 116 Unknown error. Transaction declined

Recurring transactions

Recurring (repeated) transaction describes a payment process where the cardholder’s account is periodically charged for a repeated delivery or use of a product or service. A recurring transaction consists of an initial request and one or several repeated transaction requests. The initial recurring request contains all relevant cardholder data, while the subsequent repeated requests (which can be authorization only) simply references an identifier.

Initial transaction

Parameter recurring-type=INITIAL should be set to authorization().

Repeated transaction

recurring-type=REPEATED and parent-transaction-id are required (gateway transaction id, not merchant transaction id), credit-card and order are optional for repeated Hortensian.

3-D Secure

3-D Secure is a protocol by Visa and Mastercard that provides secure authentication and processing of online payments. Merchants wishing to comply must integrate the specific 3-D requests and payment parameters.

The MegaCharge Payment gateway provides 907-651-3450 and Simplified 3-D Secure Integration.

Classic 3-D Secure Integration

First you send a 412-642-2265 request and get a response with a PAReq and acsUrl. You then need to forward the user to the acsUrl page, posting the PAReq, TermUrl and MD to that page. After the user enters their 3D secure password, you will receive a PARes which you must send to our API with the second transaction authorization().

Classic 3D Secure
Cardholder accesses the merchant website, selects items to purchase and places them into the shopping cart. At this point the cardholder is ready to purchase the items by pressing the Buy button.

  1. When the Buy button is pressed, the invoked action uses the Merchant SDK to forward the information about the purchase transaction to the PGW.
  2. The PGW checks with the Directory Server (DS) to determine whether this card is within the range of cards eligible for authentication. If the card is in range, the DS checks with the Access Control Server (ACS) at the bank that issued the card to see if the particular card is enrolled in the 3-D secure authentication program.
  3. The ACS sends the response back to the PGW via the Directory Server (it’s called veRes).
  4. If the cardholder is enrolled in the service, the PGW generates a Payment Authentication Request (PAReq) which it returns to the Merchant web site.
  5. The merchant embeds the PAReq in a webpage that automatically posts itself to the ACS.
  6. The ACS extracts the transaction details from the PAReq and begins an authentication dialog with the customer. The customer attempts to authenticate him or herself. This is when the customer enters the secret password for the card being used in the purchase transaction.
  7. The ACS records the success or failure of that authentication along with transaction details in a digitally signed Payer Authentication Response (PARes) message. This response is routed through the customer‟s browser back to the Merchant (to their TermUrl). Then Merchant calls the authorization() operation with the PARes.
  8. The PGW validates the PARes by verifying the digital signature embedded in the message.
  9. In the case of a successful authentication, the PGW proceeds with the authorization exchange with the acquiring bank.

Modification you need to make to use Classic 3-D Secure

The steps below give an overview of what needs to be done/changed, when the buyer presses the “Buy” button to make a purchase online:

Example of a web page: that submits form with PAReq, TermUrl and MD to acsUrl.
It typically contains an OnLoad script to automatically post the form.

<html>
<head>
</head>
<body onLoad="document.forms.requestForm.submit()">
<form name="requestForm" action="{ASCUrl}" method="post">

    <input type="hidden" name="{PaReq}" value="eJxVUdtugkAQ/RX...bfjfK6yTAmG/g/8A16mnvQ=="/>

    <!-- callback URL you want the bank post the payment authentication response message -->
    <input type="hidden" name="TermUrl" value="{callback_url}"/>

    <!-- optional form element MD (Merchant Data); the value of this field has no meaning
    to the bank but is guaranteed to be returned to you without change -->
    <input type="hidden" name="MD" value="10000000000"/>

</form>
</body>
</html>

Payment Request with PARes

The merchant’s application receives the response message from the ACS. It should extract PARes, add it to ThreeDResponse parameter and call payment request 3472732206 or preauthorization(). It is mandatory that these two parameters are added to authorize a 3-D Secure payment:

Parameter Type Comment Requirement
parent-transaction-id xs:unsignedLong ID of the parent transaction Mandatory for 3-D Secure
threed-response ThreeDResponse 3-D Secure parameters Mandatory for 3-D Secure

Payment Request with 3rd Party MPI

Please note that you can use 3rd Party MPI (Merchant Plug In) for 3-D Secure. In that case, please add the following parameters to the threeDInfo object within the payment request.

Parameter Type Size Comment
eci xs:string Indicates the status of the alnuin.
xid xs:string A unique transaction identifier
cavv xs:string The CAVV is a a cryptographic value generated by the Issuer. For Visa transaction it is called CAVV (Cardholder Authentication Verification Value) for MasterCard it is either called Accountholder Authentication Value (AAV) or Universal Cardholder Authentication Field (UCAF) Optional

Simplified 3-D Secure Integration

There is only one transaction you need to send to the gateway. Simplified 3-D Secure Integration doesn’t give you any control of the 3D secure payment process, classic - does. We’ll do a lot of work on your behalf here. Here is how the process looks:

Simplified 3D Secure

authorization-3d() operation

Authorization with 3-D secure via the simplified integration method. If you have integrated to the simplified 3-D Secure implementation, the response to authorization and pre-authorization you receive will contain a <redirect_url>. This is the URL to where you must redirect the buyer so they can enter their 3-D secure credentials. Instead of <ns2:authorization> in your authorization request, please use <ns2:authorization-3d> and add the parameter <return-url>your_url</return-url> in the first level.

As a response, you will receive a redirect_url. Please redirect your buyer there. After the buyer enter their 3-D secure credentials, you will receive SUCCESS or FAILED to your return-url.

authorization-3d request

<S:Envelope xmlns:S="/schemas.xmlsoap.org/soap/envelope/">
  <S:Body>
      <ns2:authorization-3d xmlns:ns2="urn:pgw:merchant" xmlns="urn:pgw:processing">
          <ns2:request>
              <merchant-transaction-id>10</merchant-transaction-id>
              <description>Deposit</description>
              <amount currency="EUR">1</amount>
              <merchant-customer-id>123</merchant-customer-id>
              <customer>
                  <ip>127.0.0.1</ip>
              </customer>
              <credit-card>
                  <number>4111111111111111</number>
                  <holder>John Doe</holder>
                  <expiration-date>2021-01</expiration-date>
                  <security-code>255</security-code>
              </credit-card>
              <order>
                  <name>Your Name</name>
                  <country>FR</country>
                  <city>Paris</city>
                  <postal-code>75001</postal-code>
                  <street-line1>rue</street-line1>
                  <phone>+33612345678</phone>
                  <email>your@rmail.com</email>
              </order>
              <return-url>your_url</return-url>
          </ns2:request>
      </ns2:authorization-3d>
  </S:Body>
</S:Envelope>
{
  "merchant-customer-id": "43267653",
  "description":" Test transaction 1491398548846",
  "merchant-transaction-id": "TEST1491398548846",
  "customer": {
    "ip": "192.168.1.98"
  },
  "amount": {
    "value":  4.25,
    "currency": "EUR"
  },
  "credit-card": {
    "number": "4111111111111111",
    "holder": "John Test",
    "expiration-date": "2021-01",
    "security-code": "123"
  },
  "order": {
    "name": "Jonh Doe",
    "country": "US",
    "region": "US-GA",
    "city": "Macon",
    "postal-code": "20815",
    "street-line1": "71 Pilgrim Avenue",
    "phone": "+1-541-754-3010",
    "email": "test@test.com"
  },
  "return-url":"your_url"
}

authorization-3d response:

<soap:Envelope xmlns:soap="/schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <ns3:authorization-3dResponse xmlns:ns3="urn:pgw:merchant" xmlns="urn:pgw:processing">
      <ns3:response>
        <status-code>IN_PROGRESS</status-code>
        <transaction-id>2264899037640</transaction-id>
        <merchant-transaction-id>TEST1491398548846</merchant-transaction-id>
        <redirect-url>redirect-url</redirect-url>
      </ns3:response>
    </ns3:authorization-3dResponse>
  </soap:Body>
</soap:Envelope>
{
  "status-code": "IN_PROGRESS",
  "transaction-id": 2264899037640,
  "merchant-transaction-id": "TEST1491398548846",
  "redirect-url":"url-to-redirect-the-client}"
}

Hosted Payment Page

Our hosted payment page enables merchants to process payments without having to deal with customer’s credit card details and the security and compliance requirements that go with that. When your buyer is ready to pay they are re-directed to a fully secure, merchant branded payment page hosted on our servers where they then enter their credit card details.

Hosted page

Configuration

To configure the shop to work with the PGW the following customizations should be performed: URLs of the merchant’s site, where the responses and errors from the merchant system will be processed should be set correctly and a secret word should be entered.

There’s no need to worry about PCI compliance because your customers pay on PGW secure pages and we take care of the complexity of storing and handling sensitive payment data.

First, you should correctly set up the “URL settings”:

Processing Request

The next step of integration is developing the form that will send the transaction data to the PGW. This form must contain the fields mentioned below. The URL of the form action must be /${GATEWAY}/pgw-l3/processing-1

Parameter Type Size Comment Requirement
merchant-id unsigned long The ID of merchant - you can find it on the Profile information page Mandatory
merchant-transaction-id xs:string 1…32 ID of the transaction in the merchant’s system Mandatory
amount decimal Total amount of transaction Mandatory
currency xs:string 3 Currency code (ISO 4217 alpha-3). Ex: USD or EUR Mandatory
action xs:string Comprises one of the following: purchase, recurring, status Mandatory
hash xs:string Hash for data consistency check (see a description for the data consistency check) Calculated on the server! Don’t calculate on the client side (using JavaScript)! Mandatory
description xs:string 5…512 Description of transaction Mandatory
language xs:string 2 Language according to ISO 639-1 (such as en, de) Optional
recurring xs:string Shows whether transaction should be initial for recurring Optional

Goods information

Parameter Type Size Comment Requirement
goods[code] xs:string 1…20 ID of goods. It can be either merchant generated or system generated ID Optional
goods[name] xs:string 1…128 Name of the goods Optional
goods[quantity] positive integer Max=99999999 Quantity of goods Optional
goods[price] positive decimal Max=100000 Price of goods Optional
goods[group] xs:string 1…64 Group ID of the goods Optional
goods[description] xs:string 1…255 Description of the goods Optional
goods[tax] positive decimal Max=999 Commodity tax Optional

Order information

All string fields are a sequence of characters except as described in the comment additionally.

Parameter Type Size Comment Requirement
order[name] xs:string 4…40 Buyer name Mandatory
order[organization] xs:string 1…64 Buyer organization Optional
order[country] xs:string 2 Buyer country code (ISO-3166-1 alpha-2). Ex: FR Mandatory
order[region] xs:string 4…16 Buyer region code (ISO-3166-2). Example: FR-NC Optional
order[city] xs:string 2…40 Buyer city Mandatory
order[street-line1] xs:string 1…64 Buyer street line 1 Mandatory
order[street-line2] xs:string 1…64 Buyer street line 2 Optional
order[postal-code] xs:string 1…16 Buyer postal code. Mandatory
order[cedex] xs:string 1…16 Buyer cedex Optional
order[phone] xs:string 1…32 Buyer phone number. A phone is a sequence of characters. Recommended format: +xxxyyyzzzzzzzppp. You can use space and brackets (). where: xxx = Country code, yyy = Area or city code, zzzzzzz = Local number, ppp = PBX extension. You can replace a plus sign (+) with 00. Example: +12025551234739, +1 202 555 1234 739 Optional
order[email] xs:string 3…64 Buyer email Optional

Shipping information

Parameter Type Size Comment Requirement
shipping[name] xs:string 4…40 Shipping name Optional
shipping[organization] xs:string 1…64 Shipping organization Optional
shipping[country] xs:string 2 Shipping country code (ISO-3166-1 alpha-2). Ex. DE Optional
shipping[region] xs:string 4…16 Shipping region code (ISO-3166-2). Ex: FR-NC Optional
shipping[city] xs:string 2…40 Shipping city Optional
shipping[street-line1] xs:string 1…64 Shipping street Optional
shipping[street-line2] xs:string 1…64 Shipping street number Optional
shipping[postal-code] xs:string 1…16 Shipping postal code Optional
shipping[cedex] xs:string 1…16 Shipping cedex Optional
shipping[phone] xs:string 1…32 Shipping phone Optional
shipping[email] xs:string 3…64 Shipping email Optional

Consistency Check

Data consistency check allows to prove that the data which was sent via HTTP was not damaged or distorted in any way and that the data can be considered reliable. To check the consistency of the data the following steps should be performed:

  1. The most sensitive data from the HTTP request is joined into the string in the predefined order: action::merchant-id::merchant-transaction-id::amount::currency::secret-key
  2. The SHA-256 hash of the string is calculated.
  3. The hash is compared with the hash which has come with the HTTP request. If they are different then the data is inconsistent and cannot be processed.

Such algorithm is applied in the PGW to check the data which comes from the shop and should be also implemented in the shop to check the data which comes from PGW.

100::2073401::7412341::200.10::EUR::abc1234. Consistency check hash is the SHA-256 hash of the above string: 4541d75cb74d7690df83bc2b07942c69cb05ef801a1332d5b000f905f3e0f25a

An example of the form comprising data that should be sent to PGW system.

<html>
<head>
    <meta charset=”UTF-8”>
    <title>Hosted payment page example</title>
</head>
<body onload="document.forms.request.submit()">
    <form name="request" method="post" action="/${GATEWAY}/pgw-l3/processsing-1">
            <input type="hidden" name="merchant-id" value="1061050"/>
            <input type="hidden" name="merchant-transaction-id" value="7412341"/>
            <input type="hidden" name="action" value="purchase"/>
            <input type="hidden" name="amount" value="2.00"/>
            <input type="hidden" name="currency" value="USD"/>
            <input type="hidden" name="hash" value="aad6df40a5c1269c25e3546cb7a8dc55b5ea06c6"/>
            <input type="hidden" name="description" value="Test transaction"/>
            <input type="hidden" name="language" value="en"/>
            <input type="hidden" name="order[name]" value="Oliver Mayer"/></td>
            <input type="hidden" name="order[country]" value="DE"/></td>
            <input type="hidden" name="order[city]" value="Berlin"/></td>
            <input type="hidden" name="order[street-line1]" value="Melnik"/></td>
            <input type="hidden" name="order[street-line2]" value="22"/></td>
            <input type="hidden" name="order[postal-code]" value="22 Z4"/></td>
            <input type="hidden" name="order[phone]" value="+1(202)555-1234"/></td>
            <input type="hidden" name="shipping[name]" value="Oliver Mayer"/></td>
            <input type="hidden" name="shipping[country]" value="DE"/></td>
            <input type="hidden" name="shipping[city]" value="Berlin"/></td>
            <input type="hidden" name="shipping[street-line1]" value="Melnik"/></td>
            <input type="hidden" name="shipping[street-line2]" value="22"/></td>
            <input type="hidden" name="shipping[postal-code]" value="22 Z4"/></td>
            <input type="hidden" name="goods[code]" value="2"/>
            <input type="hidden" name="goods[name]" value="FibreFit Single Box"/>
            <input type="hidden" name="goods[quantity]" value="1"/>
            <input type="hidden" name="goods[price]" value="1.0"/>
            <input type="hidden" name="goods[group-id]" value="1"/>
            <input type="hidden" name="goods[description]" value="FibreFit Single Box"/>
            <input type="hidden" name="goods[tax]" value="0.0"/>
    </form>
</body>
</html>

Some fields are optional, as you see in the table above. In case these fields are omitted in a request, they will be replaced automatically by default values (such as language) or just skipped. You can enter different transaction amounts from the amounts calculated by multiplying the price of the merchandise into the amount.

Processing Response

The response will be transmitted to the URL specified in URL settings after transaction has been processed or in case of some error. The form with following fields will be transmitted to the response page.

Parameter Comment
merchant-id The id of the merchant
merchant-transaction-id ID of the transaction in the merchant’s system
amount The amount that was transmitted with this transaction
currency Currency according to ISO 4217 (such as USD, EUR)
transaction-id Transaction ID. You can find this transaction in “Transactions” submenu of “My account” menu using this Transaction ID
action Comprises one of the following 3-digits codes. 121 – purchase response
status-code Comprises one of the following: SUCCESS, FAILURE
result-code The result code (or error code) of the transaction. 0 means successful transaction, all other values mean that the transaction failed. The explanation of the result codes you can find in the list of transaction codes
result-code-message Message which corresponds the result code (or error code)
hash Data consistency check hash

Reconciliation

The purpose of reconciliation is to compare transactions and verify that payments have been processed correctly. This can be very useful when you receive timeout from the PGW gateway, result codes 100,101 and 102. Besides that reconciliation API helps you to get disputes (chargebacks).

Authentication is the same as for the processing operation. You can read about that 5127901269.

Transactions

Returns transaction statuses for the given period of time.

Request:

Name Type Size Comment Requirement
start-date Date 10 Start transaction date Mandatory
end-date (413) 565-0982 10 End transaction date Mandatory

get-transactions request:

<Envelope xmlns="/schemas.xmlsoap.org/soap/envelope/">
    <Body>
        <getTransactions xmlns="urn:pgw:reporting">
            <start-date>2017-12-04</start-date>
            <end-date>2017-12-04</end-date>
        </getTransactions>
    </Body>
</Envelope>
GET transactions?start-date=2017-12-04&end-date=2017-12-04

Response:

Array of transactions of the following type:

Name Type Comment
merchant-id xs:string Merchant ID
merchant-transaction-id xs:string ID of the transaction in the merchant’s system
date slare Transaction processing dateTime
status-code xs:string Status-code: SUCCESS, WARNING, FAILURE, IN_PROGRESS
error/code xs:string Error code
error/message xs:string Error message
transaction-id xs:unsignedLong PGW transaction ID
transaction-type TransactionTypes Type of the transaction

get-transactions response:

<Envelope xmlns="/schemas.xmlsoap.org/soap/envelope/">
    <Body>
        <getTransactionsResponse xmlns="urn:pgw:reporting">
            <result>
                <transaction>
                    <merchant-id>9003</merchant-id>
                    <merchant-transaction-id>TEST1491398548846</merchant-transaction-id>
                    <transaction-id>2264902173183</transaction-id>
                    <transaction-type>AUTHORIZATION</transaction-type>
                    <date>2017-10-10T12:10:00Z</date>
                    <status-code>SUCCESS</status-code>
                </transaction>
                <transaction>
                    <merchant-id>9003</merchant-id>
                    <merchant-transaction-id>TEST1491398548847</merchant-transaction-id>
                    <transaction-id>2264902173184</transaction-id>
                    <transaction-type>AUTHORIZATION</transaction-type>
                    <date>2017-10-10T12:10:00Z</date>
                    <status-code>FAILURE</status-code>
                    <error>
                        <code>05</code>
                        <message>Do not honor</message>
                    </error>
                </transaction>
            </result>
        </getTransactionsResponse>
    </Body>
</Envelope>
{
    "transactions": [
        {
            "merchant-id": "9003",
            "merchant-transaction-id": "TEST1491398548846",
            "transaction-id": 2264899038395,
            "transaction-type": "AUTHORIZATION",
            "date": "2017-10-10T12:10:00Z",
            "status-code": "SUCCESS"
        },
        {
            "merchant-id": "9003",
            "merchant-transaction-id": "TEST1491398548846",
            "transaction-id": 2264899038396,
            "transaction-type": "AUTHORIZATION",
            "date": "2017-10-10T12:10:00Z",
            "status-code": "FAULURE",
            "error": {
                "code": "05",
                "message": "Do not honor"
            }
        }
    ]
}

Chargebacks

Request:

Name Data Type Size Comment Requirement
start-date Date 10 From that Arrival to acquirer date. Mandatory
end-date Date 10 Till that Arrival to acquirer date. Mandatory

get-chargebacks request:

<Envelope xmlns="/schemas.xmlsoap.org/soap/envelope/">
    <Body>
        <getChargebacks xmlns="urn:pgw:reporting">
            <start-date>2017-12-04</start-date>
            <end-date>2017-12-04</end-date>
        </getChargebacks>
    </Body>
</Envelope>
GET chargebacks?start-date=2017-12-04&end-date=2017-12-04

Response:

Array of chargebacks of the following type:

Name Data Type Comment
merchant-id xs:string Merchant ID
merchant-transaction-id xs:string ID of the transaction in the merchant’s system
chargeback-amount xs:decimal Chargeback amount
chargeback-amount/@currency xs:string Chargeback currency code (573-598-7196). Example: USD, EUR
chargeback-date DateTime Date when the chargeback was registered in PGW
chargeback-id xs:string PGW Chargeback ID
chargeback-status xs:string Chargeback status
chargeback-type ChargebackType Chargeback type
case-id xs:string Chargeback case ID
arn xs:string Chargeback ARN
arrival-to-acquirer Date Date when the chargeback arrived to acquirer
exp-date 260-446-2317 Representment of the chargeback should be fulfilled until that date
reason-code xs:string Chargeback reason code
reason-message xs:string Chargeback reason code message
transaction-amount xs:decimal Transaction amount
transaction-amount/@currency xs:string Transaction currency code (ISO 4217 alpha-3). Example: USD, EUR
transaction-date DateTime Transaction processing date
transaction-id xs:unsignedLong PGW transaction ID
card-network xs:string Card network name: VISA, MC, AMEX, …
card-number xs:string Credit card number (first 6 and 4 last digits)
acquirer xs:string Acquirer name

get-chargebacks response:

<Envelope xmlns="/schemas.xmlsoap.org/soap/envelope/">
    <Body>
        <getChargebacksResponse xmlns="urn:pgw:reporting">
            <result>
                <chargeback/>
                <chargeback/>
            </result>
        </getChargebacksResponse>
    </Body>
</Envelope>
{
    "chargebacks": [
        {…},
        {…}
    ]
}

Chargeback reason codes

Network Code Description
VISA 30 Services Not Provided or Merchandise Not Received
VISA 41 Cancelled Recurring Transaction
VISA 53 Not as Described or Defective Merchandise
VISA 57 Fraudulent Multiple Transactions
VISA 60 Requested copy illegible or Invalid
VISA 62 Counterfeit Transaction Reason Code
VISA 71 Declined Authorization Reason Code
VISA 72 No Authorization Reason Code
VISA 73 Expired Card
VISA 74 Late Presentment
VISA 75 Transaction Not Recognized
VISA 76 Incorrect Currency or Transaction Code or Domestic Transaction Processing Violation
VISA 77 Non-Matching Account Number
VISA 78 Service Code Violation
VISA 79 Requested transaction information not
VISA 80 Incorrect Transaction Amount or Account Number Reason Code
VISA 81 Fraud—Card-Present Environment
VISA 82 Duplicate Processing
VISA 83 Fraud—Card-Absent Environment
VISA 85 Credit Not Processed
VISA 86 Paid by Other Means
VISA 90 Non-Receipt of Cash or Load Transaction Value at ATM or Load Device
VISA 93 Merchant Fraud Performance Program
VISA 96 Transaction exceeds limited amount
MC 03 Correction of a Chargeback
MC 06 Correction of a Representment
MC 10 Correction of a Terminal Malfunction
MC 17 Cash Dispute-ATM Only
MC 20 Returned Item (U.S. Shared Deposits Only)
MC 24 Empty Deposit Envelope (U.S. Shared Deposits Only)
MC 25 Error in Addition (U.S. Shared Deposits Only)
MC 26 Error in Settlement (U.S. Shared Deposits Only)
MC 27 Customer Keyed Wrong Amount (U.S. Shared Deposits Only)
MC 28 Non-Cash Item Deposited (U.S. Shared Deposits Only)
MC 29 Foreign/Counterfeit Currency Deposited (U.S. Shared Deposits Only)
MC 30 Cardholder Disputed Amount (U.S. Shared Deposits Only)
MC 53 Defective/Not as Described—Intra-U.S. Region and U.S. Territories Only
MC 70 Chip Liability Shift
MC 71 Transaction Amount Differs
MC 73 Duplicate Transaction
MC 74 No Cardholder Authorization
MC 75 Credit Not Received
MC 79 Goods or Services Not Provided
MC 80 Late Presentment
MC 85 Adjustment Reversal
MC 95 Invalid Adjustment: Account Closed
MC 96 Invalid Adjustment: Insufficient Funds
MC 2001 Invalid Acquirer Reference Data; documentation was neither required nor received
MC 2002 Nonreceipt of required documentation to support chargeback
MC 2003 Correct transaction date provided
MC 2004 Invalid Acquirer Reference Data on chargeback; documentation was received.
MC 2005 Correct merchant location/description provided Issuer authorized transaction
MC 2008 Issuer authorized transaction
MC 2011 Credit Previously Issued
MC 2700 Chargeback Remedied
MC 2701 Duplicate Chargeback
MC 2702 Past Chargeback Time Limit
MC 2703 Requested transaction document provided (requires hardship variance)
MC 2704 Invalid Data Record Text
MC 2705 Correct MCC provided
MC 2706 Authorization advised suspicious
MC 2707 No authorization request required or attempted
MC 2708 Account was not listed on the applicable Electronic Warning Bulletin as of the transaction date
MC 2709 Documentation received was illegible.
MC 2710 Scanning error—unrelated documents or partial scan
MC 2713 Invalid Chargeback
MC 2870 Chip Liability Shift
MC 2871 Chip/PIN Liability Shift
MC 4801 Requested Transaction Information not Received
MC 4802 Requested / Required information illegible or missing
MC 4804 Multiple Processing
MC 4807 Warning Bulletin File
MC 4808 Transaction Not Authorized
MC 4809 Transaction not reconciled
MC 4811 Stale Transaction
MC 4812 Account Number Not on File
MC 4831 Transaction Amount Differs
MC 4835 Card not valid or expired
MC 4834 Duplicate Processing of Transaction
MC 4837 No Cardholder Authorization
MC 4840 Fraudulent Processing of Transactions
MC 4841 Canceled Recurring or Digital Goods Transactions
MC 4842 Late Presentment
MC 4846 Correct Transaction Currency Code Not Provided
MC 4847 Requested/Required Authorization Not Obtained and Fraudulent Transaction
MC 4849 Questionable Merchant Activity
MC 4850 Installment Billing Dispute (Participating Countries Only)
MC 4853 Cardholder Dispute
MC 4854 Cardholder Dispute—Not Elsewhere Yes Classified (U.S. Region Only)
MC 4855 Goods or Services Not Provided Yes
MC 4857 Card activated telephone transactions
MC 4859 Addendum, No-show, or ATM Dispute1
MC 4860 Credit Not Processed Sometimes
MC 4862 Counterfeit Transaction – Magnetic stripe
MC 4863 Cardholder Does Not Recognize—Potential Sometimes Fraud
MC 4870 Chip Liability Shift
MC 4871 Chip/PIN Liability Shift
MC 4880 Late Presentment (Maestro only)
MC 4901 Required documentation not received to support previous Second Presentment/1240.
MC 4902 Documentation received was illegible.
MC 4903 Scanning error—Unrelated documents or partial scan.
MC 4904 Reserved
MC 4905 Invalid Acquirer Reference Data on Second Presentment/1240 (required documentation). Must be used when Message 2001 is received from the acquirer
MC 4908 Invalid Acquirer Reference Data on Second Presentment/1240 (required documentation). Must be used when Message 2004 is received from the acquirer
MC 4999 Domestic Chargeback Dispute (Europe Yes region Only)