NAV Navbar
Shell Ruby PHP
  • Getting Started
  • Reference
  • Examples
  • Appendix
  • Transaction Statuses
  • Errors
  • Getting Started

    About Payment Gateway

    Payment Gateway is the system, which mediates and manages all payment requests, that are used to perform different functionalities and operations. Also, Payment Gateway handles the requests and customise and manage your dashboard. To get started, click on Using Payment Gateway. or go to Services to know more about our services.

    Using Payment Gateway

    Each merchant will be handed an API key, an outgoing key, and an incoming key. The merchant is identified and authenticated by the API key and a checksum calculated with request parameters and the outgoing key. The API key and incoming/outgoing keys should be treated carefully and not revealed to outsiders.

    The Merchant should specify a unique ID order_id for each transaction. This order_id will be included in the response together with a unique transaction_id.

    The API accepts POST requests and returns response data in JSON format. Some payment methods involve redirecting the user to the acquirer's website, in which case the response includes instructions about whether to use GET or POST redirection and what special parameters to include. Payment methods that involve redirection require success and error URLs to be defined.

    Authentication and Data Authenticity

    Signing requests with checksum for the following parameters and outgoing key:

    {
      "api_key": "aab1fbbca555e0e70c27",
      "currency": "EUR",
      "merchant_reference": "123",
      "order_id": "123",
      "payment_type": "cc",
      "shipping_costs": "3.50",
      "amount": "17.50"
    }
    $outgoing_key = "4d422da6fb8e3bb2749a"
    
    
    query_string="api_key=aab1fbbca555e0e70c27&currency=EUR&merchant_reference=123&order_id=123&payment_type=cc&shipping_costs=3.50&amount=17.50"
    outgoing_key="4d422da6fb8e3bb2749a"
    
    # For MacOs
    echo -n $query_string$outgoing_key | shasum | awk '{print $1}'
    
    #For Linux
    echo -n $query_string$outgoing_key | sha1sum | awk '{print $1}'
    
    # ***params*** represents the parameters you want to send
    # please replace the ***outgoing_key*** with your own, which is located under the section *`My company`* on your dashboard
    
    def calculate_checksum(params, outgoing_key)
      params_in = {}
    
      params.each do |k, v|
        params_in[k] = v || ''
      end
    
      Digest::SHA1.hexdigest(URI.encode_www_form(params_in) + outgoing_key)
    end
    
    params = [["api_key", "aab1fbbca555e0e70c27"],
              ["currency", "EUR"],
              ["merchant_reference", "123"],
              ["order_id", "123"],
              ["payment_type", "cc"],
              ["shipping_costs", "3.50"],
              ["amount", "17.50"]]
    
    outgoing_key = "4d422da6fb8e3bb2749a"
    puts calculate_checksum(params, outgoing_key)
    
    # ***params*** represents the parameters you want to send
    # please replace the ***outgoing_key*** with your own, which is located under the section *`My company`* on your dashboard
    
    
    function sign_request($params, $outgoing_key){
      $query = http_build_query($params, NULL, "&", PHP_QUERY_RFC1738);
      $checksum = sha1($query . $outgoing_key);
      return $checksum;
    }
    
    $params = array(
      "api_key" => "aab1fbbca555e0e70c27",
      "currency" => "EUR",
      "merchant_reference" => "123",
      "order_id" => "123",
      "payment_type" => "cc",
      "shipping_costs" => "3.50",
      "amount" => "17.50");
    $outgoing_key = "4d422da6fb8e3bb2749a";
    
    printf(sign_request($params, $outgoing_key));
    
    
    // ***$params*** represents the parameters you want to send
    // please replace the ***$outgoing_key*** with your own, which is located under the section *`My company`* on your dashboard
    
    

    Checksum is 9b6b075854fc3473c09700e20e19af3fbc3ff543

    Authenticated merchants are able to obtain two private keys- incoming key and outgoing key- to ensure the authenticity of the outgoing and incoming data in the requests and responses. In order to do that, requests must be signed with a checksum.

    Signing Requests with Checksum

    To prevent tampering with payment data, the parameters require signing with a checksum. The outgoing requests should be signed with the outgoing key. The API applies the following checksum calculation algorithm to verify the authenticity of the posted data.

    Checksum algorithm:

    Converting the parameters into a query string

    Spaces are encoded as plus (+) characters and special characters are encoded with a percentage sign followed by two hexadecimal digits, for more details about how to encode a query string see RFC 1738. If the "company" parameter's key has the value “John & Sons”, {"company": "John & Sons"}, the resulting string will be: company=John+%26+Sons

    Credentials

    Credentials including API key, Incoming Key and Outgoing Key as well as other information about endpoints URLs, which are needed to use the payment gateway endpoints are found in your dashboard under My Company section

    Services

    Our services allow merchants to perform different payment operations and managing their transactions through the dashboard. Each transaction has a unique identifier transaction_id, which enables the performance of certain operations for the provided payment methods as you'll see in the next section.

    Payment Methods

    The following table lists different features/operations offered for each payment method:

    Method\Operation Payment Refund Payout Recurring Payments Authorize, Capture & Reverse Precheck Other
    Credit Card X X X X Register
    Sepa Direct Debit X X X X Create Mandate Reference
    Purchase on Account X X X X
    Purchase on Account (B2B) X X X X
    Installments X X X X Calculate Rates
    giropay X X
    Sofort Überweisung X
    PayPal X X X Register
    Barzahlen X X
    Paydirekt X X
    Advance Payment X
    iDeal X X

    Credit Card

    When paying with credit card, the merchant's platform redirects the user to the payment form hosted by the Payment Gateway, where card data is entered. After completing the payment, the user is redirected back to the merchant's website. The Payment Gateway also handles payments, which need 3D verification.

    This method can also be used inside an iframe HTML tag on the merchant's website, so the user never leaves the merchant's page. After completing the payment, the web page in the merchant’s success/error URL can include a JavaScript code snippet that breaks out of the iframe if needed.

    Sepa Direct Debit

    This payment method creates a SEPA direct debit transaction based on the IBAN and BIC codes given by the end user. Unless the merchant is generating custom SEPA mandate references, the mandate needs to be created first in a separate call. This payment method has legal implications, which need to be taken into consideration.

    Purchase on Account

    It is referred to as invoice payment(Kauf auf Rechnung in Germany) and it offers users a possibility to pay the invoice after receiving the goods. To minimize the possibility of a default, invoice payment always includes a risk check procedure procedure. If the user does not pass the risk check, the response would be an error and the merchant is advised to offer the user another payment options.

    Purchase on Account B2B

    It's the same as Purchase on Account

    Installments

    Installments make it possible for the customer to pay the sum in several monthly parts. First, an installment calculation is required, which returns several options to choose from. The final payment request should include a reference to the installment calculation, that was chosen.

    Giropay

    Giropay is a service offered by GiroSolution that redirects the user to a website where they can complete the transaction by entering their bank account information and login credentials. The user confirms the transaction with their personal TAN code, after which the browser is redirected back to the merchant’s website.

    Sofort Ueberweisung

    SOFORT Überweisung is an online payment service which is offered by SOFORT AG. Technically it is very similar to giropay: the user is redirected to a payment site hosted by SOFORT and returns back to the merchant’s site after completing the transaction.

    PayPal

    PayPal is an online payment service offered by PayPal Inc. It is also very similar to SOFORT: the user is redirected to a payment site hosted by PayPal and returns back to the Merchant's site after completing the transaction.

    Paypal could be used for recurring payments, PayPal Reference Transactions are used. This is a feature PayPal only makes available on explicit request by the customer.

    Barzahlen

    Barzahlen is a special payment method that generates invoice slips and allows customers to pay at Barzahlen retail partner stores by cash. The customer receives the invoice by email or SMS and can also view it when completing the order in the merchant’s webshop. When the cash payment is registered by a retail partner store, the merchant is notified of the completed payment via the postback URL.

    Paydirekt

    Paydirekt is a payment method offered by German Banks and Sparkassen. It is also similar to Sofort, whereas the user is redirected to a payment site hosted by Paydirekt and returns back to the merchant's site after completing the transaction.

    Advance Payment

    Advance payment (Vorkasse) records transactions where the customer promises to pay the merchant.

    iDeal

    A payment method that is used in the Netherland.

    Risk Check

    Risk check involves validating the user’s address and identity (through name, date of birth and gender) as well as calculating the user’s credit score. Risk check is optional and can be enabled with every payment method, but it is always required for Purchase on Account payments. Data used in the risk check is forwarded to the scoring provider. Users always have to be informed about the risk check and give their explicit approval.
    For payment methods that have risk check enabled, the risk check is always performed first, before connecting to the acquirer with payment details. If the user does not pass the risk check, the API will return an error and the merchant should inform the user and suggest alternative payment methods.

    Reference

    Payment

    Payment Parameters

    The payment request parameters are divided into the following data blocks. This table sums up which data blocks are needed for each payment method.

    Payment Method\Parameters Common Parameters Billing Address Shipping Address Risk Check Redirection URLs Recurring (Optional) Special Parameters
    Credit Card X X X (X)
    Sepa Direct Debit X X (X) (X) Sepa Direct Debit Parameters
    Purchase on Account X X (X) X
    Purchase on Account (B2B) X X (X) X Company Details Parameters
    Installments X X (X) X
    giropay X X X
    Sofort Überweisung X X X
    PayPal X X X (X)
    Barzahlen X X
    Paydirekt X X X
    Advance Payment X X
    iDeal X X X

    Common Parameters

    The following parameters are used with all payment methods:

    Parameters Required Comments
    payment_type YES See possible payment types
    api_key YES Merchant-specific API key
    order_id YES Any alphanumeric string to identify the Merchant’s order.
    invoice_id NO Any alphanumeric string to provide the invoice number of a Merchant’s order (up to 20 characters) for factoring or debt collection
    customer_id NO Any alphanumeric string to provide the customer number of a Merchant’s order (up to 40 characters) for factoring or debt collection
    merchant _reference NO See details about merchant reference
    amount YES Including possible shipping costs and VAT (float number)
    shipping_costs NO Should be set if the order includes any shipping costs (float number)
    VAT NO VAT amount (float number) if known
    currency NO 3-letter currency code (ISO 4217). Defaults to ‘EUR’
    postback_url YES The URL for updates about transaction status are posted
    customer_ip NO If the order includes a risk check, this field can be set to prevent customers from making multiple order attempts with different personal information.
    customer_ip_proxy NO Like customer_ip, but if the order comes from behind a proxy, this additional field can be used.
    original_transaction_id NO See Original Transaction ID
    duration NO Used in installment calculation.
    locale NO The language of payment forms in Credit Card and Paypal. Possible locale values
    checksum YES A checksum of posted parameters and their values; see Checksum calculation for a complete explanation
    theme NO This is the name of the custom theme that can be set for the payment page; see Payment Page Theme
    custom_pay_text NO If parameter is passed, it will override Pay Button text in the Credit Card Payment Page

    Billing Address Parameters

    Billing information is required in all payment methods.

    Parameters Required Comments
    address YES Street address
    address2 NO Second address line
    city YES The town, district or city of the billing address
    postal_code YES The postal code or zip code of the billing address
    state NO The county, state or region of the billing address
    country YES Country Code in ISO 3166-1
    first_name YES Customer’s first name
    last_name YES Customer’s last name
    email YES Customer’s last email
    phone NO Customer’s phone number

    Shipping Address Parameters

    Shipping address can be specified when it differs from the billing address. It is required in invoice and installment payment methods.

    Parameters Required Comments
    shipping_address YES Street address
    shipping_address2 NO Second address line
    shipping_company NO name of the company of the given shipping address
    shipping_city YES The town, district or city of the shipping address
    shipping_postal_code YES The postal code or zip code of the shipping address
    shipping_state NO The county, state or region of the shipping address
    shipping_country YES Country Code in ISO 3166-1 alpha2
    shipping_first_name YES Customer’s first name
    shipping_last_name YES Customer’s last name

    Company Details Parameters

    Company details are required in B2B Purchase on Account orders.

    Parameters Required Comments
    company YES Company name
    company_vat_id NO starts with ISO 3166-1 alpha2 followed by2 to 11 characters` See more details about Vat
    company_trade_register NO Company trade registry no

    Risk Check Parameters

    If the order includes a risk check (which is always the case with Purchase on Account), the following additional parameters are required:

    Parameters Required Comments
    risk_check_approval YES This field must be set to "1" for more details See Risk Check Approval
    date_of_birth YES Customer’s date of birth; format: “YYYY-MM-DD”
    gender YES “m” for male, “f” for female

    Redirection URLs Parameters

    For payment methods that involve browser redirection, these URLs are required.

    Parameters Required Comments
    success_url YES Where to redirect the user after a successful transaction
    error_url YES Where to redirect the user after a failed transaction

    The following data are appended to the URL, which is used when redirecting back to the shop’s success/error URLs.

    It is recommended to verify the authenticity of the data by validating the checksum. This checksum is calculated like with outgoing data, only the incoming key is used this time. See Authentication and Data Authenticity for more details.

    Sepa Direct Debit Parameters

    The following additional parameters are required for a direct debit payment. If the optional sepa_mandate parameter is supplied, the create mandate reference request can be skipped when requesting a Direct Debit payment.

    Parameters Required Comments
    iban YES IBAN account number(max. 31 characters)
    bic YES BIC code(max. 11 characters)
    account_holder YES Bank account holder’s name
    sepa_mandate NO Mandate Reference Number (max. 35 characters)

    Recurring Payment Parameters

    Some payment methods can use recurring payments. For credit card payments, authorizations can be recurring as well. Here is a summary of the recurring payment flow:

    For more information about recurring payment see details about recurring and original transaction ID

    Parameters Required Comments
    recurring YES See recurring
    original_transaction_id YES(Except the first time) See original_transaction_id

    Payment Response

    Payment Payload JSON Example

    {
        "api_key":"70abd594084787a392e8",
        "payment_type":"cc",
        "order_id":"122",
        "amount":"15.9",
        "currency": "EUR",    
        "address":"WonderStr 8",
        "city":"Berlin",
        "postal_code":"666",
        "country":"DE",
        "first_name":"Chuck",
        "last_name":"Norris",
        "email":"email@email.email",
        "postback_url":"https://postback.url.com",
        "success_url":"https://success.url.com",
        "error_url":"https://error.url.com",
        "checksum":"f828dc09033fc73b6ba748a1985daa7a172a9c11"
    }
    

    Payment Request in Curl

    curl 'API_DOMAIN/rest/payment' -H 'Connection: keep-alive' --data 'payment_type=cc&api_key=70abd594084787a392e8&order_id=122&total_amount=&amount=15.9&shipping_costs=&vat=&currency=EUR&merchant_reference=Merchant+Name&company=&company_vat_id=&company_trade_register=&first_name=Chuck&last_name=Norris&email=email%email.email&address=WonderStr.+14&address2=&city=Berlin&postal_code=666&state=&country=DE&phone=&account_holder=&iban=DE89370400440532013000&bic=COBADEFFXXX&sepa_mandate=&gender=m&date_of_birth=&risk_check_approval=&customer_ip=&success_url=https%3A%2F%2Fsome.url.com&error_url=https%3A%2F%2Fsome.url.com&postback_url=https%3A%2F%2Fsome.url.com&shipping_first_name=&shipping_last_name=&shipping_company=&shipping_phone=&shipping_address=&shipping_address2=&shipping_city=&shipping_postal_code=&shipping_state=&shipping_country=&locale=&disable_validation=&theme=&checksum=854b74b8f09a433304801a182bd0d94d56c83e03' --compressed
    

    Payment Response JSON

    API_DOMAIN Could be found under the seciton My Company in Dashboard

    {
      "transaction_id":"5e02903b-0fbf-4266-affd-dc58f2749cd1",
      "order_id":"123000",
      "error_code":0,
      "status_code":1,
      "status":"started",
      "client_action":"redirect",
      "action_data": {"url":"https://some-target-url"}
    }
    

    All requests return responses in the JSON format. The following parameters are to be expected:

    Parameters Comments
    transaction_id Payment Gateway own transaction ID
    order_id The order ID specified by the merchant
    status_code Transaction’s status code
    status Transaction status in words
    error_code Error code; if this is 0, everything is fine
    error_message If the error code is other than 0, the error message will be included here.
    client_action See Client Action
    action_data See Action Data

    Barzahlen Integration

    Barzahlen Example Response

    {
      "transaction_id": "bd982c29-62f4-46de-8582-9f01cd7a076e",
      "order_id": "123000",
      "error_code": 0,
      "status_code": 2,
      "status": "pending",
      "checkout_token": "djF8Y2hrdHxzbHAtYmEwNmMzNTEtZ....ZZ2ptM1hjL3M9"
    }
    

    Embedding Barzahlen Payment Slips

    <script src="https://cdn.barzahlen.de/js/v2/checkout.js" class="bz-checkout" data-token="[checkout token from the API response]"></script>
    

    When using Barzahlen as a payment method, the return data will include the checkout token parameter. To display the Barzahlen payment slip, the merchant should embed a simple HTML code snippet that loads the JavaScript hosted by Barzahlen. The slip will display the nearest Barzahlen locations as well as the option to have the slip sent to a phone number as an SMS message (emails get sent to the customer automatically). It will be automatically loaded in a modal dialog that the customer can close. Optionally, a button can be displayed that reopens the modal dialog after closing.
    Successful Barzahlen purchases will be returned as “pending”, because the customer has not paid for the order yet. When a successful payment has been registered, the API makes a postback call and updates the transaction status to "complete". If the slip expires before the customer pays, another postback call is made with the transaction status “reversed”. The expiration period depends on the merchant’s contract with Barzahlen. Barzahlen transactions can be refunded, in which case the customer receives the refund slip by email automatically. When the refund slip is cashed, another postback call is made with the status as refunded.

    In order to embed Barzahlen payment slips form insert the html <script> tag on the right at the very bottom of the web shop page.

    For test versions, use this JS URL

    The modal dialog can be displayed again by embedding a <button> element whose class is set to “bz-checkout-btn”. For more information on Barzahlen integration, see the Barzahlen documentation

    See more Payment Examples.

    Payment Method Information

    Response Example of GET: rest/payment_info

    {
    "disclaimer": "I agree to the risk check performed by Firma AG. More information on terms and conditions available <a href='http://www.firma.de/terms'>here</a>."
    }
    

    Some payment methods, particularly the ones that use invoice and risk checks, need end user agreement. Since the legal disclaimers can vary between payment providers, there is a method to pull the disclaimer texts from Payment Gateway API. This request uses the GET method (that can be also called via JavaScript) and does not require checksums.

    Payment Method Information Parameters

    Parameters Required Comments
    api_key YES Merchant API Key
    payment_type YES See payment type
    locale NO Optional language flag for disclaimer texts (“de” or “en”). Note that some payment providers only support the German language.

    Payment Method Response

    The response includes the following attributes

    Parameters Comments
    disclaimer Disclaimer text
    risk_check Boolean(true or false) indicating whether the risk check is needed or not

    Precheck

    Calling the precheck performs the risk checks before submitting the payment. The optimal time to do this is after selecting the payment method that requires a risk check, such as Purchase on Invoice.

    Optionally, a precheck can be run without knowing the payment method yet (depending on merchant's configuration). In such a case, the payment_type parameter should be set to precheck and the response will include a list of allowed payment methods.

    Precheck Parameters

    Successful Precheck Example

    {  
       "transaction_id":"a98ce7f7-97ea-4417-bdcb-f6f4ecde4149",
       "status_code":9,
       "status":"registered",
       "order_id":"123000",
       "message":"PRE_CHECK performed successfully.",
       "error_code":0
    }
    

    Successful Precheck Example without payment method

    {  
       "transaction_id":"a98ce7f7-97ea-4417-bdcb-f6f4ecde4149",
       "status_code":9,
       "status":"registered",
       "order_id":"123000",
       "message":"PRE_CHECK performed successfully.",
       "allowed_payment_methods": ["cc", "dd", "sofort"],
       "error_code":0
    }
    

    The parameters for the precheck request are the same as in the main payment parameters request with a risk check, except that the URLs are not required. If the merchant’s order_id is not known at the time of the precheck, it can be left blank.

    If an installment calculation has been made before the precheck, the precheck request should include the selected duration parameter and the original_transaction_id parameter. The result of a successful precheck request will be a transaction, which has the status "registered".

    Precheck Response

    The successful response represents a successful created transaction and it includes the same attributes as in payment

    Authorize

    This request preauthorizes a transaction.

    Authorize Parameters

    the parameters are identical to the actual payment request, and indeed the payments can be completed using the payment request as an alias to authorization The only exception to the parameter set is reauthorization, which does not require billing or shipping addresses, only new amounts and an original_transaction_id that points to a previously authorized transaction.

    If a precheck request has been made before authorization, original_transaction_id parameter should be set the transaction id resulting from the precheck. The result of a successful invoice authorization request will have the status "pending". The result of a successful credit card authorization request will have the status “authorized”.

    Authorize Response

    Same as payment response

    Capture

    This request captures an authorized transaction. It is possible to do partial captures, but the amount may not exceed the original transaction (if it does, the transaction must be reauthorized first, which may not be supported by all payment providers). The result of a successful capture will have the status "complete".

    Capture Parameters

    Parameters Required Comments
    api_key YES Merchant API Key
    transaction_id YES ID of the transaction to be captured
    amount NO In case it differs from the original transaction(float number)
    vat NO VAT of the captured amount, if known
    checksum YES Checksum of parameters

    Capture Response

    Same as payment response

    Reverse

    This request reverses (cancels) a previous authorization. The difference to the refund request is that at this point, no money has actually changed hands. Depending on the payment processor, it may be possible to make partial reversals. Successful full reversals will have the status "reversed" whereas partial reversals will stay at "pending" (because the remaining amount can still be captured).

    Reverse Parameters

    Parameters Required Comments
    api_key YES Merchant API Key
    transaction_id YES ID of the transaction to be reversed
    amount NO In case it differs from the original transaction
    vat NO VAT of the captured amount, if known
    checksum YES Checksum of parameters

    Reverse Response

    Same as payment response

    Register

    With some payment methods, it is possible to register payment information for later billing. This is often used with credit card payments. The difference to authorization is that authorization reserves an amount on the customer’s account that has to be captured or voided, but registration simply stores the credit card data and returns the transaction ID as a token. This transaction ID can be used to make the actual transaction later. Depending on the payment service provider, the system may try to make a small authorization on the credit card and immediately void it, to ensure that the card number is actually usable. Because this method involves the end user entering credit card data, it requires redirection. Paypal pre-approved payments may be possible, but require a separate agreement between the merchant and Paypal. Here’s a summary of the registration flow:

    Register Parameters

    Parameters Required Comments
    payment_type YES “cc” (for credit card) “paypal” (for PayPal)
    api_key YES Merchant API Key
    success_url YES Where to redirect the user after a successful registration
    error_url YES Where to redirect the user after a failed registration
    postback_url YES The URL to updates about transaction status are posted
    locale NO Can be used change the language of payment forms in credit card and Paypal payments. Currently supported locales are “en” and “de”
    custom_pay_text NO This will override text on Pay button in Credit Card Payment Page
    checksum YES Checksum of parameters

    Register Response

    Same as payment response

    Installment Calculation

    The installment calculation returns a selection of monthly payment options for the installment payment method. The ID of the transaction and duration of the selected payment option resulting in the response, should be included when making payment, precheck or authorization.

    Installment Calculation Parameters

    Parameters Required Comments
    payment_type YES Payment type it should be set to "rate"
    api_key YES Merchant API Key
    amount YES total amount of the transaction(float number)
    vat NO VAT, if known

    Installment Calculation Response

    Response Example of installment Calculation

    {  
       "transaction_id":"b60cebf1-43d8-4993-8d46-f3639be4207f",
       "status_code":1,
       "status":"started",
       "error_code":0,
       "installments":[  
          {  
             "installment":[  
                {  
                   "amount":"67.17",
                   "due":"2016-06-05"
                },
                {  
                   "amount":"67.17",
                   "due":"2016-07-05"
                },
                {  
                   "amount":"67.17",
                   "due":"2016-08-05"
                }
             ],
             "original_amount":"200.00",
             "total_amount":"201.51",
             "minimum_installment_fee":"0",
             "duration":"3",
             "interest_rate":"4.95",
             "effective_interest_rate":"5.09",
             "currency":"EUR"
          },
          {  
             "installment":[  
                {  
                   "amount":"33.79",
                   "due":"2016-06-05"
                },
                {  
                   "amount":"33.79",
                   "due":"2016-07-05"
                },
                {  
                   "amount":"33.79",
                   "due":"2016-08-05"
                },
                {  
                   "amount":"33.79",
                   "due":"2016-09-05"
                },
                {  
                   "amount":"33.79",
                   "due":"2016-10-05"
                },
                {  
                   "amount":"33.79",
                   "due":"2016-11-05"
                }
             ],
             "original_amount":"200.00",
             "total_amount":"202.74",
             "minimum_installment_fee":"0",
             "duration":"6",
             "interest_rate":"4.95",
             "effective_interest_rate":"5.03",
             "currency":"EUR"
          }
       ]
    }
    
    Parameters Comments
    transaction_id Payment Gateway own transaction ID
    status_code Transaction’s status code
    status Transaction status in words
    error_code Error code; if this is 0, everything is fine
    error_message If the error code is other than 0, the error message will be included here.
    installments An array where each of its element is a json object, which contains details about an installment possibility for a monthly payment

    Refund

    There may be more than one refund per transaction, but the combined amount of refunds may not exceed the total amount of the transaction. For certain invoice/installment payment processors, it is possible to make a refund announcement (by setting announcement=1), which does not trigger the actual refund, but notifies the payment processor to stop dunning notifications.

    Refund Parameters

    Parameters Required Comments
    api_key YES Merchant API Key
    transaction_id YES Transaction to be refunded
    amount YES* Amount to be refunded; can be smaller, but not larger, than the original amount. This is required in all cases except refund announcements(float number).
    comment NO Optional comment; for internal bookkeeping, not visible to the end user
    announcement NO Set this to 1 to make a refund announcement
    checksum YES Checksum of parameters

    Refund Response

    Refund Response Example

    {  
       "transaction_id":"0b3c2327-9394-4ab4-be18-6e9d85e652fd",
       "refund_id":"6vrg2365-5232-rv27-ac2g-d852fd5e6e96",
       "status_code":1,
       "status":"successful"
    }
    
    Parameters Comments
    transaction_id Payment Gateway own transaction ID
    refund_id Payment Gateway own refund ID
    status_code Transaction’s status code
    status Transaction status in words
    error_code Error code; if this is 0, everything is fine
    error_message If the error code is other than 0, the error message will be included here.

    Payout

    Payouts are direct transfers of funds from Merchant's account to customer’s account through different payment methods. Unlike refunds, payouts don't need a previous payment and can be started independently.

    Note that in case of credit card payouts, the credit card number is required. This can be delivered in two ways: 1) if a previous credit card payment by the same customer exists, include its ID in the original_transaction_id parameter so the system can use the card's registration token (similar to making recurring credit card payments), or 2) if no previous card payment exists, the request will return a redirection directive, just like with new credit card payments. The end user should be redirected to the URL returned by the request and will be redirected back to the success/error URL after entering credit card data.

    Payout Parameters

    Parameters Required Comments
    payment_type YES See possible payment types
    api_key YES Merchant-specific API key
    order_id No Merchant’s OrderID
    amount YES Amount to be paid out to the customer (float number)
    currency YES 3-letter currency code (ISO 4217).
    original _transaction_id NO optional ID of a previous payment; useful for credit card payouts
    iban NO IBAN account number (required for direct debit)
    bic NO BIC code (required for direct debit)
    account_holder NO Bank account holder’s name (required for direct debit)
    merchant _reference NO See details about merchant reference
    address NO Street address
    address2 NO Second address line
    city NO The town, district or city of the billing address
    postal_code NO The postal code or zip code of the billing address
    state NO The county, state or region of the billing address
    country NO Country Code in ISO 3166-1 alpha2
    first_name NO Customer’s first name
    last_name NO Customer’s last name
    email NO Customer’s last email
    phone NO Customer’s phone number
    success_url NO The URL to which the end user is returned on success (required for credit card)
    error_url NO The URL to which the end user is returned on error (required for credit card)
    postback_url YES The URL for updates about transaction status are posted
    checksum YES A checksum of posted parameters and their values; see Checksum calculation for a complete explanation

    Payout Response

    Payout Response Example

    {
      "transaction_id": "0b3c2327-9394-4ab4-be18-6e9d85e652fd",
      "status_code": 2,
      "status": "pending",
      "order_id": 123000,
      "iban": "DE89370400440532013000",
      "bic": "COBADEFFXXX",
      "error_code": 0
    }
    
    Parameters Comments
    transaction_id Payment Gateway own transaction ID
    status_code Transaction’s status code
    status Transaction status in words
    order_id Merchant’s order ID
    iban Receiver's IBAN
    bic Receiver's BIC
    error_code Error code; if this is 0, everything is fine
    error_message If the error code is other than 0, the error message will be included here.

    Mandate Reference

    A Direct Debit/SEPA Payment relies on a mandate. This can be supplied via the optional sepa_mandate parameter or a mandate reference code has to be generated first. This code must be communicated to the user/bank account holder and is the basis for mandates. After the call to create_mandate_reference the Direct Debit payment request has to be made with the field original_transaction_id set to the transaction_id of the response.

    Mandate Reference Parameters

    Parameters Required Comments
    payment_type YES "dd" for direct debit
    api_key YES Merchant-specific API key

    Mandate Reference Response

    Mandate Reference Response Example

    {
      "transaction_id": "48e2c6cc-58b5-46e1-9f48-6e9d85e652fd",
      "status_code": 9,
      "status": "registered",
      "order_id": 123000,
      "error_code": 0,
      "token": "81fceb646f1c86b8a8209dd5cdd3300e"
    }
    
    Parameters Comments
    transaction_id Payment Gateway own transaction ID
    status_code Transaction’s status code
    status Transaction status in words
    order_id Merchant’s order ID
    error_code Error code; if this is 0, everything is fine
    error_message If the error code is other than 0, the error message will be included here.
    token Mandate reference token

    Postbacks

    On completing the transaction, the API will perform a POST request to the URL specified in postback_url before redirecting the user to the Merchant’s website. The purpose of this additional request is to pass transaction information to the Merchant without the end user seeing the contents, and to ensure the Merchant is informed about completing the transaction even if the user for some reason does not return to the Merchant’s website. The following data will be posted in all postback requests:

    Parameters Comments
    transaction_id ID of the transactions
    status_code Status code
    status Status name
    order_id Merchant’s order ID
    message Additional info about the transactions status
    checksum Checksum of parameters

    Transactions

    List of transactions

    Listing Transactions Request Example

    curl '/rest/transactions?api_key=70abd594084787a392e8&from=2016-10-05T17%3A50%3A28%2B02%3A00&to=2016-11-05T18%3A50%3A28%2B02%3A00&status=&currency=&checksum=0d1b84623b5da5ab4c3f6f3386b8497664ccb96a'
    

    Listing Transactions response

    [  
       {  
          "transaction_id":"4927d679-7695-4a31-a901-e89dcfed3d43",
          "created_at":"2016-10-26T16:04:33.901+02:00",
          "updated_at":"2016-10-26T16:05:00.897+02:00",
          "status_code":2,
          "status":"pending",
          "amount":612.85,
          "currency":"EUR",
          "order_id":"145000188",
          "recurring": 0,
          "sepa_mandate": null,
          "parent_id": null,
          "payment_method":"kar",
          "message":"PRE_AUTH performed successfully.",
          "sepa_msg_id":null
       },
       {  
          "transaction_id":"07c8b0a4-186f-4b56-a929-17d13b29c695",
          "created_at":"2016-10-26T16:03:06.394+02:00",
          "updated_at":"2016-10-26T16:03:06.416+02:00",
          "status_code":9,
          "status":"registered",
          "amount":0.0,
          "currency":"EUR",
          "order_id":null,
          "recurring": 0,
          "sepa_mandate": null,
          "parent_id": null,
          "payment_method":"dd",
          "message":null,
          "sepa_msg_id":null
       }
    ]
    

    When sending a GET request without specifying the transaction ID, the API returns the last 50 transactions. Otherwise one could use the following parameters to get a list of specific transactions

    List of transactions Parameters

    Parameters Required Comments
    api_key YES Merchant-specific API key
    from NO Optional earliest date in ISO-8601, e.g. 2016-10-05T17:50:28+02:00
    to NO Optional latest date in ISO-8601, e.g. 2016-10-05T18:50:28+02:00
    status NO Optional status code or a comma-separated list of status codes, e.g. status=3 or status=2,3
    currency NO Optional 3-letter currency code (ISO 4217)
    checksum YES Checksum of parameters

    List of Transactions Response

    The response will be an array of json objects. Each has the body of the single transaction response

    Single Transaction

    Single Transaction Parameters

    The request should include the following parameters:

    Parameters Required Comments
    api_key YES Merchant-specific API key
    id YES The ID of the requested transaction
    checksum YES Checksum of parameters

    Single Transaction Response

    Single Transaction Request Example

    curl '/rest/transactions/1d477fa1-38af-4cba-a93f-363c20146314?api_key=70abd594084787a392e8&id=1d477fa1-38af-4cba-a93f-363c20146314&checksum=337195202be6c7ec21cac5b0d1160f46f901681c'
    

    Single Transaction Response

    {  
       "transaction_id":"1d477fa1-38af-4cba-a93f-363c20146314",
       "created_at":"2017-12-21T12:28:25.632+01:00",
       "updated_at":"2017-12-21T12:28:25.689+01:00",
       "status_code":9,
       "status":"registered",
       "amount":0.0,
       "currency":"EUR",
       "order_id":"12300",
       "recurring": 0,
       "sepa_mandate": null,
       "parent_id": null,
       "payment_method":"dd",
       "message":null,
       "sepa_msg_id":null
    }
    

    Here are a list of parameters that could be included in the response

    Parameters Comments
    transaction_id ID of the transactions
    status_code Status code
    status Status name
    amount amount used in this transaction(float number)
    currency Code of the currency that have been used
    order_id Merchant’s order ID
    payment_method (Payment method)(#payment_type)
    message Message about the transaction
    spea_message_id Sepa message ID
    sepa_mandate Mandate Reference Number (max. 35 characters)

    Transaction Summary

    Transaction summary request example

    curl '/rest/transactions/summary?api_key=70abd594084787a392e8&from=2016-10-05T17%3A50%3A28%2B02%3A00&to=2016-11-05T18%3A50%3A28%2B02%3A00&status=Eur&currency=&checksum=27bdbeb8f0c7b15adda7dfff59856c5409eda6bb'
    

    Transaction summary response example

    {
      "count":9,
      "total_amount":858.75
    }
    

    When the number of transactions is large, but going through individual transactions is not desired, it is possible to query statistics on transactions by embedding /summary at the end of the request. This will return the total sum of transaction amounts and the number of transactions found in the data set

    Transaction Summary Parameters

    Parameters Required Comments
    api_key YES Merchant-specific API key
    from NO Optional earliest date in ISO-8601, e.g. 2016-10-05T17:50:28+02:00
    to NO Optional latest date in ISO-8601, e.g. 2016-10-05T18:50:28+02:00
    status NO Optional status code or a comma-separated list of status codes, e.g. status=3 or status=2,3
    currency NO Optional 3-letter currency code(ISO 4217)
    checksum YES Checksum of parameters

    Transaction Summary Response

    Parameters Comments
    count the number of transactions
    total_amount the total transacted amount of the Transactions (float number)

    Transaction Status Change

    The transaction status can be changed over the API, provided that certain conditions are met. For instance, a pending transaction can be marked as completed when the invoice has been paid by the customer, but an already cancelled transaction cannot be marked as complete again

    Transaction Status Change Parameters

    Parameters Required Comments
    api_key YES Merchant-specific API key
    status YES The new status
    transaction_id YES ID of the transactions
    debt_collection_id NO debt collection ID
    checksum YES Merchant-specific API key

    Transaction Status Change Response

    Parameters Comments
    transaction_id ID of the transactions
    status_code Status code
    status Status name
    amount amount used in this transaction(float number)
    currency Code of the currency that have been used
    order_id Merchant’s order ID
    payment_method Payment method
    message Message about the transaction
    spea_message_id Sepa message ID
    sepa_mandate Mandate Reference Number (max. 35 characters)

    Transaction Debt Collection

    Some transactions be sent to debt collection or factoring, if they are still in the pending state after two weeks and if a debt collector has been set up with the merchant. The exact conditions (as well as the whether the transaction will be sent to debt collection or factoring) depend on the merchant's configuration.

    The result is a JSON object of transaction details, just like in the single transaction request. If a debt claim has been successfully submitted, the status will be "debt_collection" or "factoring".

    Payment Page theme settings

    The payment page can be customized with a color theme. The parameters of the page are listed in the following table and each parameter can be altered with an API call. Please note that color values c1 to c10 can be given in hex or rgba color codes. If no value is given for an optional parameter then the default color from the payment page will be used.

    Payment Page theme parameters

    Payment Page theme settings

    Parameters Required Comments
    name YES theme name for url path
    font NO CSS fonts
    c1 NO input field text(hex or rgba)
    c2 NO background(hex or rgba)
    c3 NO border(hex or rgba)
    c4 NO input field background, submit button text(hex or rgba)
    c5 NO submit button, input field label (hex or rgba)
    c6 NO info button background (hex or rgba)
    c7 NO info button background on hover (hex or rgba)
    c8 NO info box background (hex or rgba)
    c9 NO info box text (hex or rgba)
    c10 NO submit button on hover (hex or rgba)
    checksum YES checksum of the sent parameters

    List of merchant themes

    The request requires the merchant’s api_key and a valid checksum. The response is a JSON file with all current themes that belong to this merchant.

    Setting up a new theme

    It requires a merchant’s api_key, a valid checksum and a unique name in order to be stored and the response includes the same sent parameters in addition to the created_at and updated_at field.

    Setting up a new them response example

    {  
       "id":17,
       "merchant_id":212,
       "name":"My Theme",
       "font":"Fira Sans",
       "c1":"#868686",
       "c2":"#fff",
       "c3":"#abb0b6",
       "c4":"#fefefe",
       "c5":"#59A618",
       "c6":"rgba(111, 208, 30, 1)",
       "c7":"rgba(255, 204, 0, 1)",
       "c8":"#ffc73e",
       "c9":"#0a0a0a",
       "c10":"#77de20",
       "created_at":"2018-02-20T13:29:22.454+01:00",
       "updated_at":"2018-02-20T13:29:22.454+01:00"
    }
    

    Updating an existing theme

    This action requires the merchant’s api_key and a valid checksum to be passed with the PATCH request and the response includes the same sent parameters in addition to the created_at and updated_at field.

    Showing a specific theme

    the corresponding theme id. The merchant’s api_key and a valid checksum is required to perform a GET request and the response includes the (page them parameter)(#payment-page-theme-parameters) in addition to the created_at and updated_at field.

    Import Invoices

    API calls to rest/import requires Basic Authentication

    Basic authentication is a simple authentication scheme built into the HTTP protocol.

    You send HTTP requests with the Authorization header that contains the word Basic followed by a space and a base64-encoded string api_key:outgoing_key.

    For example, to authorize as 9eca1a5cacbed63fd932:7423655f519517490af0 then you would send: json Authorization: Basic OWVjYTFhNWNhY2JlZDYzZmQ5MzI6NzQyMzY1NWY1MTk1MTc0OTBhZjA= attached to header of the post request.

    Import Invoices Parameters

    Example JSON Body

    {
        "url_name": "test_url",
        "batch_name": "your import reference(batch name)",
        "invoices":
        [
            {
                "debt_claim_number":"123",
                "amount": 1.99,
                "print_date": "12.10.2018",
                "first_name":"Peter",
                "last_name":"Mustermann",
                "address":"Egal Str. 1",
                "postal_code":"10434",
                "city":"Berlin",
                "country":"Deutschland"
            },
            {
                "debt_claim_number":"124",
                "amount": 1.94,
                "print_date": "2.3.2018",
                "first_name":"Petra",
                "last_name":"Mustermann",
                "address":"Egal Str. 1",
                "postal_code":"10434",
                "city":"Berlin",
                "country":"Deutschland"
            }
        ]
    }
    

    Successful JSON Response

    {
        "status": "completed",
        "message": "Imported"
    }
    

    The import invoices request parameters are divided into the following data blocks. This table sums up which data blocks are needed for each invoice import.

    Parameters Required Comments
    url_name YES URL prefix of the channel
    batch_name NO optional reference for import batch
    debt_claim_number YES your invoice number
    amount YES amount to be paid, only numeric values
    print_date YES billing date
    first_name NO first name of the payer
    last_name NO last name of the payer
    address NO address of the payer
    postal_code NO postal code of the payer
    city NO city of the payer
    country NO the full name of the country i.e. "Germany" or "Deutschland"
    description NO some description about this invoice

    Examples

    Payment Examples

    Payment Request with Action Required Response

    Action Required: Form

    Action Required: Form

    Response Example

    {  
       "transaction_id":"e851ba99-3a8e-4614-93c5-e5421ccc3a7d",
       "order_id":"123456789",
       "error_code":0,
       "status_code":1,
       "status":"started",
       "client_action":"postform",
       "action_data":{  
          "url":"https://payment.girosolution.de/payment/start",
          "fields":{  
             "urlRedirect":"https://api.example.com/payment_response/7",
             "urlNotify":"https://api.example.com/payment_postback/7",
             "sourceId":"6da0f976433e18641662198d98557955",
             "merchantId":"3606200",
             "projectId":"5678",
             "amount":"15.9",
             "transactionId":"e851ba99-3a8e-4614-93c5-e5421ccc3a7d",
             "currency":"EUR",
             "vwz":"Merchant Name",
             "bankcode":null,
             "hash":"841ecab99510a0692578bd9404567e40"
          }
       }
    }
    

    On the left is an example of a response that instructs the merchant to build a form and immediately submit it. client_action specifies that there is a form that should be posted, and action_data includes the target URL and fields with their values. This way the Payment Gateway API does not have to render the form, eliminating one link in the redirection chain. This action is currently only used by the giropay payment method.

    Action Required: Redirection

    Action Required: Redirection

    Response Example

    {  
       "transaction_id":"ab824a32-552f-4468-875e-ba9603c6a2f1",
       "order_id":"123000",
       "error_code":0,
       "status_code":1,
       "status":"started",
       "client_action":"redirect",
       "action_data":{  
          "url":"https://www.sofort.com/payment/go/94296bbd19b39b806bc9dc540b9e4a8aa00eae1b"
       }
    }
    

    Some payment processors, such as SOFORT, generate a URL for each transaction, where the user can be redirected with no POST parameters required. In such cases, client_action key is set to “redirect” and the target URL is included in action_data. See the response sample on the left

    Error Response Example

    {
      "error_code": 101,
      "error_message": "Merchant not found."
    }
    

    Appendix

    Parameters Details

    Payment Parameters

    Payment Type

    Locale

    The following languages options are available:

    Merchant Reference

    What to display as the reference on the customer’s bank statement.

    Risk Check Approval

    The customer must explicitly give his or her approval to risk check. If the value is anything else than "1", an error is triggered.

    Client action

    After posting a payment request the action could be a postform or a redirect as the following:

    Action Data

    If client_action is specified, this array includes the following data:

    Recurring

    This parameter is set to 1 when a merchant wants to make a recurring payment.

    Original Transaction ID

    This parameter is used to perform a payment after

    Whereas the original_transaction_id is the first successful transaction ID, which all later payments are based on it and it could be obtained from the successful response of one of the possible three requests above.

    In order to conform with International and German Law, information about the SEPA purchase needs to be shown to the paying customer in the case of a initial SEPA payment. Here is one example how such a information text might look like:

    Mandate reference:
    I hereby legitimate to conduct payments via direct debit to settle outstanding amounts. I further instruct my bank to service direct debit payments initiated by .
    Surname, name: #surname>, #name
    Street, number: #Street, #No
    Postcode, city: #post code, #city
    Holder name: #holder name
    IBAN: #iban
    BIC: #bic
    Notice: Within eight weeks time from the date of charge, you can demand a full refund of the charged amount. Please regard the terms and conditions for refunds of your bank, which apply.
    "checkbox (required)" I hereby confirm that I have the authority to grant the mandate to the SEPA direct debit transaction(s) displayed above. I hereby grant the mandate.

    Be aware that the text for a recurring mandate differs from this. Additionally a customer must receive a pre notification if a recurring payment occurs, the text of the pre-notification might look something like:

    We debit your bank account with € 12.70 maturing March 13th 2015.
    The customer must also be informed about the mandate number (not to be confused with mandate reference). This number can be shown after the payment has been processed, or be sent via Email later.

    Test data

    Credit Card

    Visa

    Any name could be used and the ccv will be ignored.
    expiration date should be somewhen in the future. The amount between 100 and 500€ will be rejected by the acquirer

    Master Card

    Any name could be used and the ccv will be ignored.
    expiration date should be somewhen in the future. The amount between 100 and 500€ will be refused by the acquirer

    giropay

    1. Amount: 1110000300 -> produces a successful transaction
    2. Amount: 1110000310 -> produces a rejected transaction
    3. Amount: 1110000390 -> produces a transaction with unknown error(simulates random errors like timeouts or unreachable bank).We’ll mark it as “error” but it needs further attention)

    Sofort

    Paydirekt

    User Name Password Restrictions
    SDE-Kaeufer SDE-Kaeufer2$ standard user
    unterAchtzehn unterAchtzehn22$ user under 18 years old
    KauferGesperrt KauferGesperrt2$ buyers of paydirekt are blocked
    SperreKB SperreKB2$ buyers of the buyers' bank are blocked

    Paypal

    Sepa Lastschrift

    Barzahlen

    Although the transactions would be created here but they won't be marked as completed by the system.

    Kauf auf Rechnung(Bonitätsprüfung):

    Transaction Statuses

    Code Status Description
    1 started Transaction has been started; user has been redirected to the acquirer’s website.
    Transactions that remain in this state for longer than an hour should be considered aborted by the user.
    2 pending Credit card payments: The user submitted the payment, but the acquirer has marked the transaction as pending; this usually means that it takes longer than average to complete the transaction.
    Invoice payments: The order has been accepted, but payment has to be confirmed manually by the merchant or captured over the API (depending on the acquirer).
    The pending status is treated as a successful payment; the API returns a successful state or redirects to the merchant's success URL
    3 completed Credit card payments: The acquirer has marked the transaction as completed.
    Invoice payments: the merchant marked pending transaction as paid in the merchant portal.
    Payment is successful; API returns a successful state or redirects to success URL
    4 error There has been an error with the transaction.
    API returns an error state or redirects to the shop’s error URL
    5 canceled User has canceled the payment on the acquirer’s website.
    API redirects to the error URL or returns a canceled status
    6 declined The acquirer has declined the payment. Payments that require a risk check are marked as declined if the risk check fails.
    API returns a declined state or redirects to the shop’s error URL
    7 refunded There are partial or full refunds for this transaction.
    This status is usually not returned by the API but visible in the merchant portal after refunds have been made.
    8 authorized The payment has been authorized successfully but not yet executed.
    This payment should be captured or reversed later.
    9 registered A credit card has been registered for this transaction but payment has not been executed.
    OR:
    A successful precheck has been completed but the transaction is not yet authorized.
    This transaction should be completed using thepayment request
    10 debt_collection A debt collection process has been initiated for this transaction.
    The transaction has gone into debt collection; awaiting further status updates.
    11 debt_paid The debt collection process has been completed for this transaction.
    The debt has been collected and the transaction is considered successful.
    12 reversed Authorization has been reversed (canceled).
    The transaction is considered canceled.
    13 chargeback A Chargeback has been issued for a completed or pending transaction.
    14 factoring The transaction has entered factoring
    The transaction is considered successful because the merchant is assumed to have received the money from the factoring party.
    15 debt_declined Debt collection has been declined (for instance, because of insufficient data).
    16 factoring_declined Factoring has been declined (for instance, because of insufficient risk checks).

    Errors

    The API can return the following errors with explanation messages

    The Kittn API uses the following error codes:

    Error Code Message Meaning
    101 Merchant not found. The Merchant does not exist or was not recognized.
    Check api_key.
    102 Transaction not found. Transaction does not exist. Rare; may occur when redirecting back from the acquirer.
    Try again later; contact us
    103 The checksum does not match. the calculation algorithm or the outgoing key is invalid.
    Check the checksum calculation algorithm and the outgoing key. Pay particular attention not to confuse outgoing and incoming keys.
    104 Unsupported payment type. Payment method does not exist or merchant does not have this payment method.
    Check payment_type.
    105 Deprecated. ---
    106 The payment processor is not responding. Acquirer’s service is not responding.
    Try again later.
    107 There has been an error with the payment processor. Acquirer’s service is not functioning and is returning errors.
    Try again later.
    108 Payment error Acquirer returned a payment-related error. Includes more information in the message if available.
    Look into the error message; contact us..
    109 Merchant does not have payment processor for this payment type. No acquirer has been defined for the merchant.
    contact us.
    110 Customer did not agree to the risk check process required by this payment method. Customer must explicitly agree to the risk check process.
    Check risk_check_approval; remind the customer that risk check must be approved.
    111 Risk check processor not found. System error; rare
    112 Customer did not pass the risk check. Customer had insufficient risk check score, wasn’t identified by the risk check service or the address does not exist.
    Inform the customer and suggest alternative payment methods.
    113 There has been an error with the risk check. Error in the risk check processor’s service.
    Try again later.
    114 Too many risk check attempts from this address. Customer from the same IP has attempted to submit an order (and failed the risk check) multiple times, possibly with different personal/address data
    . Suggest alternative payment methods.
    115 Payment provider not found. System error; rare
    116 Risk check adapter not found. System error; rare
    117 Payment adapter not found. System error; rare
    118 Recurring payment could not find the original transaction. You are trying to run a recurring transaction, but the original transaction was not found.
    Check original_transaction_id.
    119 This payment processor does not support recurring payments. You are trying to make a recurring payment with an acquirer that doesn’t support recurring payments.
    Make a new non-recurring transaction.
    120 Recurring payment could not find the original payment token. The tokens needed to make a repeat transaction with the acquirer could not be found. Most likely the acquirer did not support recurring payments at the time of the original transaction.
    Make a new non-recurring transaction.
    121 This payment processor does not support refunds. Refunds cannot be made for this acquirer.
    If the transaction absolutely has to be refunded, contact us.
    122 The refunded amount cannot exceed the original amount. Combined amount of past refunds for this transaction is larger than the original amount.
    Check the amount to be refunded
    123 This currency is not supported. The selected currency is not supported by this acquirer.
    Try another currency
    124 Invalid country code. The country has not been specified in the correct format.
    Make sure the country code is in the ISO 3166-1 format.
    125 Invalid or missing return URLs. No valid return URLs have been specified in the payment request.
    Check the parameters success_url, error_url and postback_url.
    126 Invalid bank account information. The bank data of a direct debit transaction does not pass the validation.
    Check IBAN and BIC.
    127 This payment processor does not support authorization. The payment processor does not support authorize/capture/reverse operations.
    Use payment call or contact us
    128 Transaction has not been authorized for capture or reverse operation. The status of transaction is other than “authorized”, that is, it has already been captured or reversed or was not authorized to begin with.
    Create a new payment.
    129 Deprecated ---
    130 Error converting legacy bank information to IBAN/BIC. (No longer used, because legacy parameters are no longer accepted.)
    Use IBAN/BIC instead
    131 This payment processor does not support Mandate generation. SEPA Mandate generation cannot be used with this payment processor
    use paymentcall
    132 Reserved Reserved
    133 Payouts not supported. Payment processor does not support payouts
    Make sure the payment processor you are using supports payouts
    134 Amount cannot be zero or negative. Payments with zero or negative amounts are rejected by all acquirers.
    Only send payments with an amount greater than zero.
    135 Payouts not supported. Payment processor does not support payouts.
    Make sure the payment processor you are using supports payouts.
    136 Transaction status change not possible. The status change is not permitted or logical, for example trying to change a cancelled transaction to completed.
    Try another status or contact us.
    137 Debt collector not found. The debt collector assigned for the merchant does not exist or is not working.
    138 Debt collections for this merchant are not supported. This merchant does not have debt collections enabled.
    139 The debt collector returned an error
    140 Amount submitted to debt collection does not match transaction amount The verify_amount option, if used, must match the transaction amount
    Verify that the transaction amount is correct before retrying.
    141 Factoring allowance exceeded. Merchant has exceeded the limit of factored transaction amounts within a set time limit.
    Contact us to raise the limit or try again in a new calendar month/year (depending on settings)
    142 Age conditions for debt claim are not met. Transaction is too new or too old to be sent to debt collection or factoring.
    Try again later or contact us to change age limits.
    144 Unauthorized. The passed credentials are invalid.
    Check your api_key and outgoing_key
    145 Channel cannot be found. The Channel submitted under url_name does not exist or was not recognized.
    Check url_name.
    146 Import error: related error message. Error message explains why the error occured.