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:
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' testingtestMode=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