API Parameters Reference

Introduction

This reference section provides you with a complete and in-depth description of the PrimeiroPayment Platform API.‌

​Hosts​

  • Test: https://test.oppwa.com/

  • Live: https://oppwa.com/

​Security / Authentication​

All requests must be sent over SSL‌

All requests are authenticated against an Authorization Bearer header with an access token. All the other data parameters are sent as body parameters, see Authentication Parameters for more information.‌

​Throttling​

Throttling is the process of limiting the number of requests submitted to a given operation in a given amount of time. Throttling protects the web service from being overwhelmed with requests and ensures providing a healthy web service.‌

Following throttling values has been configured:‌

Live system

Show throttling details‌

Test system

Show throttling details‌

Requests which will be affected by throttling, will be rejected with following return code:

{
   "buildNumber":"b297e8ec4aa0888454578e292c67546d4c6a5c28@2018-08-30 06:31:46 +****",
   "id":"8ac9a4a8658afc790165a3f0e436198d",
   "ndc":"8acda4c9635ea2d90163636f0a462510_ebb07f3e26e942908d6eeed03a813237",
   "result":{
      "code":"800.120.100",
      "description":"Too many requests. Please try again later."
   },
   "timestamp":"2018-09-04 09:42:33+0000"
}

​Versioning​

The API version is indicated in the request URL e.g. /v1/payments indicates version 1.‌

All changes made to the API are backwards compatible, hence any major features that are released, that would otherwise break existing implementations, will be released using a new version.‌

​Encoding​

Our system expects data to be sent encoded in UTF-8.‌

Using this Content-Type header can help:‌

application/x-www-form-urlencoded; charset=UTF-8

​HTTP Status Codes​

For each request you send to our API the HTTP status code of the response will already tell you the basic result.‌

200 - successful request‌

307 - temporary redirect‌

400 - bad request. This might either point to e.g. invalid parameters or values sent. It's also returned if the payment failed e.g. because the acquirer declined.‌

401 - invalid authorization header provided‌

403 - invalid access token provided‌

404 - requested resource or endpoint is not found. I.e. endpoint/url doesn't exist. This can also be caused by typos like POST /v1/paymnets instead of payments or wrong IDs like GET /v1/payments/{id} where no payment with {id} exists.‌

For payments you'll want more fine grained information to find out why a payment failed. You're getting this information in the result codes.‌

​Testing​

It is important to note that we have two test modes available to cause requests to be sent to our connector simulator or to the connector's own test platform, as required:‌

  • testMode=EXTERNAL causes test transactions to be forwarded to the processor's test system for 'end-to-end' testing

  • testMode=INTERNAL causes transactions to be sent to our simulators, which is useful when switching to the live endpoint for connectivity testing.

If no testMode parameter is sent, testMode=INTERNAL is the default behaviour‌

​Credit Card Test Accounts​

Test Bank Accounts (SEPA)

This reference lists all the PrimeiroPayment Platform parameters, grouped by their data structures.‌

Basic Payment

Authentication

To make REST API calls, include the access token in the Authorization header with the Bearer authentication scheme.

Card Account

The card data structure holds all information regarding a credit or debit card account.

Apple Pay

There are two possible APIs for Apple Pay:‌

Apple Pay with encrypted payment token

You can send the encrypted payment token as-is. We will do the decryption and process the transaction.

Apple Pay with decrypted card information

You can do the decryption by yourself and send us the decrypted card information with the usual card API: card.number, card.expiryMonth, card.expiryYear, threeDSecure.verificationId, threeDSecure.eci, and the following parameter:

Virtual Account

The virtual account data structure is used to send account-based payments, e.g. PAYPAL.

Bank Account

The bank account data structure holds all the information that specifies a bank account. This is used for bank-account based payments, e.g. direct debits, SEPA and bank transfers. Collecting money from the shopper's bank account generally requires his approval. SEPA specific parameters - bankAccount.mandate.id, bankAccount.mandate.dateOfSignature,transactionDueDate are not used in the risk checks.

Customer

The customer data structure holds information about the customer/shopper such as their name, identification documents and contact details. The customer fields serve mixed purposes: On the one hand they are just for you to store information on your customers, but on the other hand they are also used and sometimes required for risk management and payment providers that require ID/mandate information. These use cases are noted in the parameters' descriptions.

Shipping customer

The shipping customer has the same fields than the billing customer, just as part of the shipping entity. That way you can ship to an entirely different customer.

Billing Address

The billing address holds the address of the customer. Information sent in the billing address data structure can optionally be used for risk checks such as AVS for card processing.

Shipping Address

The shipping address holds the location and recipient of ordered goods. This can be used for risk processing or logistics.

Merchant

The merchant data structure holds information about you, the merchant (acceptor). These fields can be used to override the information that is shown on the cardholder statement. It can also be used for payment facilitators.

Cart

Cart items

The cart data structure holds product information about the shopping cart such as the product's ID, name, quantity and price. The cart items are counted up by changing the index-number [n], starting with 0, and maximum 1000. Example: cart.items[0].name=First Cart Item

Cart payments

The cart payments data structure holds information about already made payments associated with the cart. The cart payments are counted up by changing the index-number [n], starting with 0. Example: cart.payments[0].name=First Cart Item

Airline

The airline data structure holds passenger and trip leg airline information. The airline passenger and leg items are counted up by changing the index-number [n], starting with 0. Example: airline.passengers[0].name=Jane Jones

Tokenization and Registration

As described in the Tokenization Guide there are two ways to store a customer's data on the system. Either directly POST to the registration endpoint or add the following parameter to a payment:

Recurring

As described in the Recurring Payments Guide, all you have to do for sending recurring transactions is to flag the transaction with the following parameter:

Recurring Migration

To do a migration of recurring payment you need to do a registration (RG) with INITIAL transaction data that are send with the following parameters:

3D Secure

The 3D secure data structure is used to hold authentication data generated by the 3D secure MPI when an external MPI is being used, or additional information about the authentication. If 3D data is present which indicates the usage of an external MPI (xid, eci, verificationId), the payment gateway will just pass through these values to the acquiring system. For more detailed information about the required fields for 3D Secure version 2.0 and above, please visit the 3D Secure 2.0 guide here

Custom Parameters

Custom parameters are unspecified fields that can be used to send custom data. The data sent in these fields are echoed back in the response.

Asynchronous payments

Asynchronous payment methods like 3D secure, online transfer or virtual wallets have additional steps in their workflow. The response to your initial payment request will be pending and contain a redirect URL to the receiver system that the shopper should be forwarded to.

The response parameters:

Webhook Notifications

When you register a webhook, you'll receive notifications on the registered Url. These notifications are basically standard responses (wrapped in the "payload") of different types.

In addition to standard response parameters, these notifications specific are available:

Reporting

The following parameters are used when calling the reporting endpoints.

Giftcard

A giftcard allows you to send additional information for payments and risk checks that have a gift card.

Risk

The following parameters are additional parameters available for risk checks e.g. using the ReD Shield.

Scheduling Payment Jobs

The following parameters are additional parameters available for scheduling payment jobs

Payment Response Parameters

Reconciliation Response Parameters

Reconciliation reporting data is available via CSV file from FTP. The structure of the reconciliation reporting csv file is as of following:‌

ReconciliationType;PaymentType;Cashflow;ClearingInstituteMerchantId;MerchantAccountId;MerchantAccountName;PspId;DivisionId;MerchantId;SettlementTxId;UniqueID;ShortId;ConnectorTxId1;ConnectorTxId2;ConnectorTxId3;Amount;Currency;Brand;TxRequestTime;SettlementAmount;SettlementCurrency;SettlementFee;SettlementFxRate;SettlementDate;SettlementStatus;Descriptor;AccountNumberLast4;BankCode;AccountHolder;ReasonCode;ReasonDesc;SettlementFileFormat;ClearingInsitituteName;MatchingStatus;MatchedTransactions;ChargebackId

Card On File

Following are all the parameters needed for sending card on file transactions.

Last updated