The easypay API is a collection of web services that allow you to receive payments from customers, be notified of those payments, refund them if necessary, among others.

The API endpoints are available through the following domains:

• For test environment:

    https://api.test.easypay.pt/
  

• For production environment:

    https://api.prod.easypay.pt/
  

To create credentials for your account you can follow this guide.

Server-to-server requests to easypay APIs must be authenticated via Account ID and API Key. To do so, include the following HTTP headers in your API requests:

AccountId: <YOUR_ACCOUNT_ID>
ApiKey: <YOUR_API_KEY>

When these headers are missing or incorrect, a 403 HTTP status code is returned.

For your convenience, during tests you can use the following ID/Key pair:

AccountId: 2b0f63e2-9fb5-4e52-aca0-b4bf0339bbe6
ApiKey: eae4aa59-8e5b-4ec2-887d-b02768481a92

These will only work for testing purposes and won't work in production.

Easypay uses HTTP response status codes to indicate the success or failure of your API requests. If your request fails, Easypay returns an error using the appropriate status code.

In general, there are three status code ranges you can expect:

• 2xx success status codes confirm that your request worked as expected
• 4xx error status codes indicate an error because of the information provided (for example, a required parameter was omitted).
• 5xx error status codes are rare and indicate an error with Easypay’s servers.

Some 4xx errors that could be handled programmatically (for example, a card is declined) include an error code (a short string with a brief explanation) as a value for code.

Below is a list of possible error codes that can be returned, along with additional information about how to resolve them. For your convenience, these types of errors also include the doc_url attribute with a direct link to the specific error code it corresponds to.

Authentication Error

This error can have multiple potential causes. Here are some examples:

• Missing/Invalid AccountId and/or ApiKey Headers
• Your account has been blocked
• You don't enough permissions to the action requested

Invalid Content Type Error

This error can only have one cause, you provided an invalid/unsupported content type header.

Invalid JSON Error

This error happens when you provide a bad formated JSON payload.

Invalid Params Error

This error indicates the information provided was incorrect of insufficient (for example, a required parameter was omitted).

Internal Error

This error indicates that an unexpected error ocurred on our servers.

Safe Retries in Easypay API: The Role and Implementation of Idempotency Keys

Easypay API incorporates idempotency that enables the safe re-submission of requests, eliminating the risk of unintentionally duplicating operations.

This helps to circumvent unintentional replication due to failures and retries.

For instance, in an event of a timeout error, you can securely resend the same API payment call several times, assured that the payment detail will be debited only once.

To execute an idempotent request, simply include an additional Idempotency-Key header within the request parameters.

curl -L -X POST 'https://api.test.easypay.pt/2.0/checkout' \
  -H 'AccountId: 2b0f63e2-9fb5-4e52-aca0-b4bf0339bbe6' \
  -H 'ApiKey: eae4aa59-8e5b-4ec2-887d-b02768481a92' \
  -H 'Idempotency-Key: 435e08a0-e5a9-4216-acb5-44d6b96de612' \
  -H 'Content-Type: application/json' \
  --data-raw '{ "type": [ "single" ] ... }'

You can check if a request is a replay by checking if the Idempotency-Replay Header is present in the response and if it has the value "true".

Generating Idempotency Keys

Although the technique of creating unique keys is your choice, remember random string with sufficient entropy to prevent overlaps is advisable.

Easypay recommends the use of UUID V4 or ULID as Idempotency Key.

The maximum length for idempotency key is 50 characters.

How it works

Two requests with the same Idempotency-Key but different AccountId headers will be treated as different requests.

Easypay manages idempotency by storing the initial status code and response body for the initial request with a specific idempotency key.

The Idempotency layer compares the request body of the incoming request with that of the original request.

If they differ, the system triggers an error to prevent inadvertent misuse.

Repeated requests bearing the same key yield identical outcomes. The only exception pertains to transient errors, which we have identified as the following:

• Too Many Requests (HTTP status code 429)
• Bad Gateway (HTTP status code 502)
• Service Unavailable (HTTP status code 503)

The previously mentioned error codes are safe to retry.

To help the client applications decide whether to retry calls, the API's responses include an X-Easypay-Should-Retry header with value "true" or "false". Note that this header does not take into account the number of tries already made, so clients should keep track and only send a limited number of equal requests (e.g. 3).

If and when the header is not present, clients can use the following strategy to determine what to do:

1. If no response was received at all, resend the request.
2. If the response has one of the following status codes, resend the request:
   • Conflict (HTTP status code 409), may indicate the original request was still in transit
   • Too Many Requests (HTTP status code 429)
   • Bad Gateway (HTTP status code 502)
   • Service Unavailable (HTTP status code 503)
3. If the response has status code 500 (Internal Server Error), resend the request as long as it's not a POST request.
4. Otherwise, don't repeat the request and handle the error.

Idempotency Keys are automatically purged from the system once they've been in existence for 24 hours, and a fresh request is initiated if a key is reused after its original has been deleted.

Only results from API endpoints that have started execution are stored.

If your request fails authentication, it will not be governed by idempotency rules.

Idempotency keys are acceptable in all POST/PATCH requests.

It is unnecessary and should be avoided to supply idempotency keys in GET and DELETE requests, as these types of requests are inherently idempotent by nature.

Payment methods are defined according to two different categories:

• Pull / Push: The merchant requests the funds from the customer, or the customer sends the funds directly to the merchant.
• Synchronous / Asynchronous: The charge happens immediately, or only after a period of time.

Pull or Push

Each method of payment is categorized as either pull or push, depending on how funds are transferred from the customer’s payment method.

• In a method with a pull behaviour, the customer needs only to accept the payment request from the merchant. Credit card payments and MB WAY are examples of the described behaviour. On the credit card, the customer accepts the payment by providing his credit card details, while on MB WAY they accept by interacting with the push notification on the smartphone.

• In a method with a push behaviour, the customer takes the initiative of sending the funds to the merchant. Virtual IBAN or Multibanco are examples of such behaviour. On the Virtual IBAN, the customer should go to their bank account and create a SEPA transfer to the provided IBAN. On Multibanco, the customer should go to an ATM and create a payment to the entity and reference provided.

Credit / Debit Card

A Credit / Debit card is a payment card issued to users (cardholders) to enable the cardholder to pay a merchant for a good or service. This is a synchronous pull payment method. This means that the payment happens immediately. Credit / Debit cards also support authorizations where you can hold an amount for later capture.

Apple Pay

Apple Pay is a mobile payment and digital wallet service by Apple Inc. that allows users to make payments in iOS apps, and on the web using Safari. It is supported on the iPhone, Apple Watch, iPad, and Mac. Apple Pay is a synchronous pull payment method. This means that the payment happens immediately when the customer authorizes it using their Apple device. The merchant requests the payment, and the customer approves it on their device, which sends the payment to the merchant. Apple Pay does not require the customer to create any additional accounts or fill out an extensive form for each purchase. It utilizes the cards already on file in a user’s Apple Wallet. Apple Pay uses a method called tokenization to secure card information. Tokenization replaces the card number with a unique alphanumeric identifier, referred to as a token. The token is used for communication between the merchant, the bank, and Apple Pay, ensuring the actual card number is never shared with the merchant or transmitted with the payment.

Please note that Apple Pay is not available in all regions and is subject to the terms and conditions of the card issuer.

Google Pay™

Google Pay is a mobile payment method that enables customers to pay using credit or debit cards stored in their Google Account. It is a synchronous pull payment method, meaning payments are processed immediately upon customer authorization. Google Pay primarily uses a tokenized solution for enhanced security, which most issuers accept as compliant with Strong Customer Authentication (SCA), eliminating the need for 3D-Secure (3DS) in many cases.

Fallback for Non-Tokenized Transactions: If a transaction isn’t tokenized or the issuer requires additional authentication, the system will automatically trigger the 3DS flow to ensure payment success.

Compatibility and Requirements: Google Pay is fully compatible with existing features like recurring payments and can be integrated seamlessly into websites and apps. It requires serving the payment page over HTTPS with a TLS domain-validated certificate for secure transactions.

Usage: This payment method supports transactions for physical goods, donations, subscriptions, and more. The integration process involves enabling Google Pay in your payment methods settings, with minimal code implementation required when using certain payment platforms.

Regions and Limitations: Google Pay's availability depends on the user's region. All merchants must adhere to the Google Pay APIs Acceptable Use Policy and accept the terms defined in the Google Pay API Terms of Service.

MB WAY

MB WAY is a Portuguese local method. To use MB WAY, the customer must have a Portuguese Banking account as well as a smartphone Bank/MB WAY app installed. This is a synchronous pull payment method. The Merchant will issue a payment request that will trigger a push notification on the customer application. MB WAY also supports authorizations where you can hold an amount for later capture.

Multibanco

Multibanco is a Portuguese local method. This is an asynchronous push payment method. The Merchant creates a payment request that will generate the Multibanco order details. The details include:

• An entity number
• A reference number
• The amount to pay To pay, the customer introduces these details in an ATM or in their homebanking system.

This payment method has some edge cases that you should be aware of, such as the ones below:

• The customer can pay a different amount than the requested;
• Multibanco refunds are not currently supported by the vendor. If refunds are needed, you can offer them via SEPA Transfer.

Direct Debit

Direct Debit is an asynchronous pull payment method in which a merchant withdraws funds from the customer's bank account. To do so, the customer must accept a SEPA Direct Debit (SDD) Mandate, which can be valid for multiple payments (therefore supporting single, frequent and subscription payments). To create the SDD Mandate, the merchant must supply the customer's name and IBAN.

Depending on the customer's bank, confirmations of Direct Debit payments may take up to 14 days. Direct Debit is not recommended for single payments due to the risk of fraudulent customers issuing chargebacks.

Virtual IBAN

Virtual IBAN is an asynchronous push payment method that follows the same principles of SEPA Bank Transfers: the merchant provides the customer with an IBAN and transfer amount that they should introduce in an ATM or homebanking system to specify the bank account to which funds are to be transferred.

In comparison with regular SEPA Transfers, Virtual IBAN has the benefit of protecting your bank account details by providing you with a virtual bank account number that supports single, frequent and subscription payments.

Although transfers to a single-use Virtual IBAN after the first payment are initially accepted by the customer's bank (and thus funds are temporarily withdrawn), they are automatically refunded by the IBAN issuer bank.

Universo Flex

Universo Flex is a Portuguese local synchronous pull payment method similar to Credit Card, allowing the merchant to accept payments in 3 to 24 installments without having to be a credit intermediary.

Santander Consumer Finance

Santander Consumer Finance is a Portuguese local asynchronous pull payment method where the customer applies for a loan to acquire the good or service in installments. The merchant does not need to be a credit intermediary.

Single

Single payments are one-time transactions that will let your customers pay an amount of money to you. Examples may include a purchase of a good or service, or a donation. Every payment method supported by easypay allows single payments.

You can accept single payments entirely through our Checkout solution or by calling our Payments API.

Frequent

Frequent payments are repeatable transactions of varying sums without the client having to enter their payment details again. The original details can be obtained (tokenized) through our Checkout solution, but each payment will have to be charged via the Payments API.

It is possible to limit the transferred sums by choosing minimum or maximum values, either to the total sum of the transactions or each individual transaction.

Supported methods for frequent payments are: Credit Card, MB WAY, Multibanco, Direct Debit, and Virtual IBAN.

Subscription

Subscriptions are periodic payments of the same amount of money, configured through Checkout or our Payments API.

Subscriptions support a number of different frequencies, ranging from daily to once every three years. Their last payment can be determined by the end date of the subscription, as well as the total number of payments captured. They also support a configurable number of retries for each capture in case of failure, as well as falling back to another (single) payment method if the recurring one is not successful.

Supported methods for subscriptions are: Credit Card and Direct Debit.

Certain payment methods like credit card and MB WAY go through two distinct phases: authorisation and capture. Our integrations allow you to move through them separately (issuing a card authorisation first and later capturing the funds) or in a single step referred to in our APIs as sale (authorisation followed by capture).

Authorisation

Authorisation is the first step of the process and involves guaranteeing that the buyer has sufficient funds or credit available to make the payment. If so, the funds are put on hold: the customer cannot use them to pay for other goods or services, but they're not yet transferred to the merchant's account. If the merchant fails to capture the funds in the following days, the hold is lifted.

Authorisations are useful to make sure customers have the means to purchase your product/service before actually charging them. You can issue the authorisation at the moment an order is placed and only actually transfer the funds when you ship the items or provide the service. Another interesting use case of authorisations is multi-captures.

Capture

A capture is the actual transfer of funds from the buyer to the merchant.

Sale

In many of our integrations, specifying sale as the type of operation will automatically perform an authorisation and a capture, immediatelly transferring the funds from the customer to the merchant in a single step (if successful).

Multi-captures

It is also possible to issue an authorisation for a value that will later be split among different captures. One example is a store supporting split payments for orders of multiple vendors. The full amount of the order is authorised but the different captures can be issued at different times, after each vendor confirms or ships the goods.

Single payments are one-time transactions that will let your customers pay an amount of money to you.
Examples may include a purchase of a good or service, or a donation.
Every payment method supported by easypay allows single payments.

Multibanco Reference

When calling the API 2.0 in single, our system returns an entity and reference in the response JSON. When the payment is made by the customer, our system sends a Generic Notification with the Single ID. Upon receipt, your system should call the Single Details endpoint with the Single ID reported as successful in order to confirm it.

MBWay

Upon successfully calling API 2.0 on a Single with type sale, our system will communicate to the end customer's MBWAY App. After the event of the customer accepting/declining the payment, our system sends a Generic Notification with the Single ID and a status (success or failed). Upon receipt of success, your system should call Single Details endpoint with the Single ID reported as successful in order to confirm it.

Only for Test Environment, we have these possible cases on phone:

  911234567 - Authorized for all operations
  917654321 - Failed for all operations
  913456789 - Declined for all operations
  919876543 - Pending for all operations

Visa & Mastercard

By successfully calling the API 2.0 in a Single with type sale, our system returns a URL in the response JSON for the client to be forwarded to our credit card gateway. The end customer must enter the card data. Our system validates the card in the VISA / MASTERCARD and sends a Generic Notification with the Single ID and a status (success or failed). Upon receipt of a success, your system should call the Single Details endpoint with the Single ID reported as successful in order to confirm it.

For Visa forward and Visa details configurations follow this link

Only for Test Environment, we have these possible credit card numbers:

  0000000000000000 - Authorized for all operations
  2222222222222222 - Proceed with 3DS authentication
  1111111111111111 - Failed for all operations
  1234123412341234 - Declined for all operations

SEPA Direct Debit

By successfully calling the API 2.0 in a Single with type sale, our system returns a URL in the response JSON for the client to be forwarded to our credit card gateway. The end customer must enter the card data. Our system validates the card in the VISA / MASTERCARD and sends a Generic Notification with the Single ID and a status (success or failed). Upon receipt of a success, your system should call the Single Details endpoint with the Single ID reported as successful in order to confirm it.

Only for Test Environment, all valid iban will return success but this one: PT50000201231234567890154

Virtual IBAN

When calling the API 2.0 in single, our system returns an IBAN in the response JSON. When the payment is made by the customer, our system sends a Generic Notification with the Single ID. Upon receipt, your system should call the Single Details endpoint with the Single ID reported as successful in order to confirm it.

Santander Consumer

By successfully calling the API 2.0 in a Single, our system returns a URL in the response JSON for the client to be forwarded to. The end customer must fullfill the journey in the Santander Consumer page. After the journey is completed with success, our system sends a Generic Notification with the Single ID. Upon receipt, your system should call the Single Details endpoint with the Single ID reported as successful in order to confirm it.

Universo Flex

By successfully calling the API 2.0 in a Single with type sale, our system returns a URL in the response JSON for the client to be forwarded to. The end customer must fullfill the journey in the Universo Flex page. After the journey is completed with success or failure, our system sends a Generic Notification with the Single ID. Upon receipt, your system should call the Single Details endpoint with the Single ID reported as successful in order to confirm it.

For Visa forward and Visa details configurations follow this link

Payments used on frequent services with amounts and periodicity changes

Multibanco Reference

After one Frequent MB request our system will return an entity and a reference in the JSON response. The customer can always pay between the min and max values several times before the expiration date or when the method Deletes Frequent is called with success. If the parameter unlimited_payments is active transactions will be unlimited, entity and reference is reseted on our provider 3 times a day, otherwise the total value of payments can’t exceed the max defined. For each payment made with this entity and reference, our system sends a Generic Notification with the Frequent ID.

MBWay

After successfully calling the API 2.0 on a Frequent MBW you can capture funds through the Frequent ID on a Capture call, our system will communicate to the end customer's MBWAY App. If the final customer accepts / rejects payment, the system sends a Generic Notification with the Capture ID and a status (success or failed). Upon successful receipt, the system should call the Frequent Details endpoint with the Frequent ID reported as successful in order to confirm it.

Only for Test Environment, we have these possible cases on phone:

  911234567 - Authorized for all operations
  917654321 - Declined for all operations
  919876543 - Pending for all operations

Visa & Mastercard

When calling the API 2.0 successfully on a Frequent CC, the system returns a URL in JSON for the client to be forwarded to our credit card gateway. The end customer must enter the card data. The system validates the card in the VISA / MASTERCARD and notifies Generic Notification with the Frequent ID and a status (success or failed). Upon successful receipt, the system should call the Frequent Details endpoint with the Frequent ID reported as successful. From a successful communication, you can capture funds using the Frequent ID in a Capture call. The system will capture the funds from the card and sends a Generic Notification with the Capture ID and a status (success or failed). Upon successful receipt, the system should call the Frequent Details endpoint with the Frequent ID reported as successful.

For Visa forward and Visa details configurations follow this link.

SEPA Direct Debit

When calling API 2.0 successfully on a Frequent DD, the system returns in JSON including the SEPA Direct Debit Mandate ID and an additional entity/reference for additional payments. From now on funds can be captured through the Frequent ID using the Capture endpoint, these funds can take up to 48 business hours to obtain a SEPA direct debit response. When responding, the system notifies with Generic Notification with the Capture ID and a status (success or failed). Upon successful receipt, the system should call the Frequent Details endpoint with the Frequent ID reported as successful.