NAV
shell

Introduction

Welcome to the MYMOID API!

We define how MYMOID’s payment API works throughout this section. This documentation is directed to the development departments of businesses that want to integrate with it. Therefore, it has a technical nature.

This guide assumes that your company has been previously registered and that it has the necessary credentials to be able to interact with the payment API. MYMOID’s API consists of an API REST with a series of services secured by unique credentials assigned to each business.

Our main concepts are based on the next three entities: Payment Order, Payment Method and Payment. Within the platform these entities interact with each other to carry out the payment process and store the information about it.

The entire API is based on the concept of a Payment Order. This Payment Order reflects a payment and the interaction between a business and a client. As such, this document makes constant references to this term, which is defined in more detail in the corresponding section.

Environments

MYMOID’s API has two environments: Sandbox and Production.

MYMOID Environments

Sandbox environment

The Sandbox environment is dedicated to integration trials for new companies.

In this environment, there is no real movement of money and all the tests are performed with a testing card and actual payment cards cannot be entered as it will not work. The configuration data of this environment are:

mymoidServerUrl: https://sandbox.mymoid.com

The testing card available to operate in this environment is the following:

Field Value
Cardholder any
Card number 4548812049400004
Expiration date 12/20
CVV 123

Production environment

The Production environment is the real environment. All the operations in this environment are valid and it only accepts actual cards. The configuration data of this environment are:

mymoidServerUrl: https://api.mymoid.com

Application

When you create a new merchant in our platform, an application is the entity responsible for storing the credentials and permissions for the merchant. These applications make different credentials with each other that can be configured with special permissions to perform certain types of operations.

Permissions

Name Description
GENERATION Generate and consult the application Payment Orders.
PAY Pay, refund and cancel the application Payment Orders.
REUSE Reuse the application already paid Payment Orders.
MASTER This permission contain all the permissions listed before and also can operate over all the Payment Orders created for the merchant.

Authentication

All not public API calls must have a specific HTTP header in all their requests in order to be able to identify and validate the application of the business which performs the calls. The header which must be used is the enabled ‘Authorization’, which by definition, can authenticate the requests received. The content that the header must carry is composed this way:

'Basic ' + Base64( APP_ID + ':' + APP_SECRET)

Where the APP_ID (Application ID) is the unique identifier of the Application and APP_SECRET (Application Secret Key) is the secret key for the same application. MYMOID expects for the API key to be included in all API requests to the server in a header that looks like the following:

Authorization: Basic Base64Value

Example

In first place, the APP_ID must be linked, followed by the symbol ’:’ to the APP_SECRET. We will convert this to Base64 and we will link the result later to the 'Basic’ text (between the word Basic and the calculated Base64 there will be a blank space). We can see how to compose it with the following example data:

APP_ID: 5f93015589fcea018f0c2d97bd0a3508186a8b7d360591b0547d0743de2fe284

APP_SECRET: 97158fbb7852bfa0661033650a721ff7b97a3c1a0d41aafaa680b6f68c786196

Base64 calculated using above APP_ID and SECRET_KEY:

NWY5MzAxNTU4OWZjZWEwMThmMGMyZDk3YmQwYTM1MDgxODZhOGI3ZDM2MDU5MWIwNTQ3ZDA3NDNkZTJmZTI4NDo5NzE1OGZiYjc4NTJiZmEwNjYxMDMzNjUwYTcyMWZmN2I5N2EzYzFhMGQ0MWFhZmFhNjgwYjZmNjhjNzg2MTk2

Then the authorization header for the example credentials will be:

Basic NWY5MzAxNTU4OWZjZWEwMThmMGMyZDk3YmQwYTM1MDgxODZhOGI3ZDM2MDU5MWIwNTQ3ZDA3NDNkZTJmZTI4NDo5NzE1OGZiYjc4NTJiZmEwNjYxMDMzNjUwYTcyMWZmN2I5N2EzYzFhMGQ0MWFhZmFhNjgwYjZmNjhjNzg2MTk2

Payment order

In order to make a Payment, we first need to create a Payment Order. After creating a Payment Order we can interact with it to perform different types of transactions such as consultation, execution, cancellation or refund.

This payment order has two diferent types, this types would decide the flow in the payment. The follow workflows will explain the diference between this two payment types.

Standard payment Workflow

Preauthorization payment Workflow

Payment Order statuses

Status Description
AVAILABLE The initial status of a Payment Order after it has been created. This Payment Order can be expired, canceled or paid.
EXPIRED A Payment Order is expired if the expiry period (24 hours by default) has passed and the payment on it has not been made. Once the Payment Order has expired it cannot be paid.
CANCELLED A Payment Order with AVAILABLE status may be cancelled. After we cancelled the Payment Order it cannot be paid.
PREAUTH When you Preauthorize a payment order, you are effectively ring-fencing funds in your customer’s bank account in order to confirm the payment later. A Payment Order can only arrive to this status from AVAILABLE.
PAID Only after we confirm or excecute a Payment the Payment Order status would be PAID.
PARTIALLY_REFUNDED A Payment Order is in this status if we make a refund for an amount less than the total after having been paid.
REFUNDED The amount associated to the Payment Order which was previously paid has been completely refunded. To be able to proceed to a refund, the Payment Order must be in PAID or PARTIALLY_REFUNDED status.

Payment Order attributes

Attribute Description
currencyCode The type of currency associated to the payment order.
reference Payment Order’s reference.
concept Payment Order’s concept.
amount Payment Order’s amount. This should be an integer value (decimals are not accepted) and represents the value in cents. To order a 1 EUR payment order (or any other currency) the value must be 100.
payType Payment Order’s type. The right value for execute a traditional payment should be entered is PAY. But In order to use the preauthorizations you should use ‘PREAUTH’ as a payment order type.
status Payment Order’s status (detailed in the payment order section).
paymentOrderId Payment Order’s identifier.
shortCode Payment Order’s short identifier.
merchantId Merchant’s identifier that generate the order.

Preauthorization attributtes

Attribute Description
paymentId Payment identifier.
operationDate Execution date.
amount Transaction’s value.
currency Transaction’s currency.
processorName Gateway processor name.
entityProcessorCode Gateway merchant code.
authorizationCode Gateway athorization code.
transactionCode Gateway transaction unique identifier.
paymentOperationType Transaction Type.

Payment attributtes

Attribute Description
paymentId Payment identifier.
operationDate Execution date.
amount Transaction’s value.
currency Transaction’s currency.
processorName Gateway processor name.
entityProcessorCode Gateway merchant code.
authorizationCode Gateway athorization code.
transactionCode Gateway transaction unique identifier.
paymentOperationType Transaction Type.

Refund attributtes

Attribute Description
paymentId Identifier of the Payment corresponding to the refund. Once you execute a refund a new Payment entity with negative value is created. This new Payment is related to the initial Payment Order.
operationDate Execution date.
amount Value of the Refund. This amount would be negative in order to represent the Payment Refund.
paymentOperationType Transaction Type.

Creating a Payment Order

Example Standard body:

{
  "currency": "EUR",
  "concept": "Oxford Shoes - Spanish Leather",
  "reference": "OXF-3479",
  "amount": 18400,
  "payType": "PAY",
  "expirationDate":"2017-11-29 12:26:00"
}

Example Preauthorization body:

{
  "currency": "EUR",
  "concept": "Oxford Shoes - Spanish Leather",
  "reference": "OXF-3479",
  "amount": 18400,
  "payType": "PREAUTH",
  "expirationDate":"2017-11-29 12:26:00"
}

Response by the API:

{
  "status": true,
  "code": 0,
  "data": {
    "paymentOrderId": "2e0d250097047b7abf1528fd271dd08cb8bc7b3fb7f51e37b3c8fc5c1eb19ec8",
    "shortCode": "JZ3PLK",
    "currencyCode": "EUR",
    "amount": 18400,
    "merchantId": "282682dd6b19c81ee7d6b3322505ebe20e03467c0a6dac129c2206e5202ba375",
    "concept": "Oxford Shoes - Spanish Leather",
    "reference": "OXF-3479",
    "status": "AVAILABLE",
    "currentStatus": {},
    "creationDate": 1454490217151
  }
}

After defining Payment Order and the different statuses for Payment Orders, we will see how we can create one through the API. To do so, we must make the following request:

POST {mymoidServerUrl}/views/button/order

You can find API request and response examples aside.

As of this moment, all the operations that we want to make on the payment orders that we have created we will have to indicate the paymentOrderId received at the moment of creating a payment order. This unique, 64-character ID will allow us to indicate at all times which payment order we are working with. It is also important to remember the value returned in the shortCode key. This unique identifier also represents a payment order and we will need it when loading the payment form that we will discuss later.

Checking the status of a Payment Order

Response by the API:

{
  "status": true,
  "code": 0,
  "data": {
    "paymentOrderId": "2e0d250097047b7abf1528fd271dd08cb8bc7b3fb7f51e37b3c8fc5c1eb19ec8",
    "shortCode": "JZ3PLK",
    "currencyCode": "EUR",
    "amount": 18400,
    "merchantId": "282682dd6b19c81ee7d6b3322505ebe20e03467c0a6dac129c2206e5202ba375",
    "concept": "Oxford Shoes - Spanish Leather",
    "reference": "OXF-3479",
    "status": "AVAILABLE",
    "currentStatus": {},
    "creationDate": 1454490217151
  }
}

Once a Payment order has been created, we can consult its status at any time. This request provides us the up-to-date information associated with the received Payment Order as a parameter. To do so, we have to perform the following call to the API:

GET {mymoidServerUrl}/pay/order/{paymentOrderId}

The paymentOrderId is the Payment Order identifier that we want to consult. You can see the response from the API to this request aside.

If the Payment Order is in the PAID status, we can see two fields that will be useful for us: pan and expirationCard. The pan reflects the last four digits of the card used to make the Payment, while expirationCard shows its expiration date.

Cancelling a Payment Order

Response by the API:

{
  "status": true,
  "code": 0,
  "data": {
    "paymentOrderId": "2e0d250097047b7abf1528fd271dd08cb8bc7b3fb7f51e37b3c8fc5c1eb19ec8",
    "shortCode": "JZ3PLK",
    "currencyCode": "EUR",
    "amount": 18400,
    "merchantId": "282682dd6b19c81ee7d6b3322505ebe20e03467c0a6dac129c2206e5202ba375",
    "concept": "Oxford Shoes - Spanish Leather",
    "reference": "OXF-3479",
    "status": "CANCELLED",
    "currentStatus": {},
    "creationDate": 1454490217151
  }
}

After creating a Payment Order, we have the possibility to cancel it whenever it is in AVAILABLE status and it has not passed its expiry period. After cancelling the Payment Order we will not be able to perform any other action with it, and therefore we cannot proceed to Payment. In order to cancel a Payment Order, the following request must be performed:

PUT {mymoidServerUrl}/pay/order/cancel/{paymentOrderId}

You can find API response aside.

Executing a Payment Order

Example body:

{
  "expirationDate": "2022-07-01",
  "creditCardType": "VISA",
  "cardNumber": "4548810000000003",
  "cvv": "052",
  "holderName": "John Doe",
  "type": "CREDIT_CARD"
}

OK response by the API:

{
  "status": true,
  "code": 0,
  "data": {
    "paymentOrderId": "2e0d250097047b7abf1528fd271dd08cb8bc7b3fb7f51e37b3c8fc5c1eb19ec8",
    "shortCode": "JZ3PLK",
    "currencyCode": "EUR",
    "amount": 18400,
    "merchantId": "282682dd6b19c81ee7d6b3322505ebe20e03467c0a6dac129c2206e5202ba375",
    "concept": "Oxford Shoes - Spanish Leather",
    "reference": "OXF-3479",
    "status": "PAID",
    "currentStatus": {},
    "expirationCard": "02/20",
    "pan": "454881XXXXXX0003",
    "creationDate": 1454490217151
  }
}

Through the following request we can execute a Payment Order:

{mymoidServerUrl}/pay/order/execute/{paymentOrderId}/anonymous

In case of not fulfilling the certification required for this transaction MYMOID provides a Payment Form with which the orders can be executed, please, refer to Payment form documentation to know more about it.

Unauthorize a Preauthorization (Preauthorization Only)

To release the previous reserved (authorized) funds it is necessary to execute a cancellation of the payment order, this will return the funds automatically and cancel the payment order.

In order to view payment order cancelation, please, refer to Cancelling a Payment Order documentation.

Confirming a Preauthorization (Preauthorization Only)

After you reserve the funds on the client’s bank account, you should confirm this transaction in order to make it effective (The funds reserved against the client’s bank account will be charged and will be travelling to your merchant account).

Partially Confirm

Response by the API:

{
  "status": true,
  "code": 0,
  "data": {
      "paymentOrderId": "b562f9b396085544d958f03e930122250ea0ad42c100860d6fcb86404368a616",
      "shortCode": "PQ2LMH",
      "currencyCode": "EUR",
      "amount": 18400,
      "merchantId": "a63c1c35c746c7be262fa971a80466b1543c7eed39b17eab2256a1b4214522c3",
      "reference": "OXF-3479",
      "concept": "Oxford Shoes - Spanish Leather",
      "status": "PAID",
      "currentStatus": {},
      "creationDate": 1511781955000
  }
}

As we explain before, once a Payment order has been preauthorized, we can confirm a partiall amount from the reserved founds using the next request:

{mymoidServerUrl}/pay/order/confirm/{paymentOrderId}/{amountToConfirm}

Confirm

Response by the API:

{
  "status": true,
  "code": 0,
  "data": {
      "paymentOrderId": "b562f9b396085544d958f03e930122250ea0ad42c100860d6fcb86404368a616",
      "shortCode": "PQ2LMH",
      "currencyCode": "EUR",
      "amount": 18400,
      "merchantId": "a63c1c35c746c7be262fa971a80466b1543c7eed39b17eab2256a1b4214522c3",
      "reference": "OXF-3479",
      "concept": "Oxford Shoes - Spanish Leather",
      "status": "PAID",
      "currentStatus": {},
      "creationDate": 1511781955000
  }
}

In order to confirm the full amount of the preauthorization, you can use the following request:

{mymoidServerUrl}/pay/order/confirm/{paymentOrderId}

Refunding a Payment Order

As we explain in the Payment Order Section when we have a Payment Order in PAID status, we can make a refund. There are two different kind of refunds explained below:

a) Partial refund

Partial refund - Response by the API:

{
  "status": true,
  "code": 0,
  "data": {
    "paymentOrderId": "2e0d250097047b7abf1528fd271dd08cb8bc7b3fb7f51e37b3c8fc5c1eb19ec8",
    "shortCode": "JZ3PLK",
    "currencyCode": "EUR",
    "amount": 18400,
    "merchantId": "282682dd6b19c81ee7d6b3322505ebe20e03467c0a6dac129c2206e5202ba375",
    "concept": "Oxford Shoes - Spanish Leather",
    "reference": "OXF-3479",
    "status": "PARTIALLY_REFUNDED",
    "currentStatus": {},
    "creationDate": 1454490217151
  }

With the partial refund we have the possibility of refunding an amount less than the amount associated with the Payment Order and make multiple refunds, whenever the refunded amount in total is less than or equal to the total amount of the Payment Order.

In this case we indicate the amount to refund. If the amount to refund is equal to the total amount of the payment order, the partial refund would be equal to the total refund.

Url of the request:

PUT {mymoidServerUrl}/pay/order/refund/{paymentOrderId}/amount/{amount}

b) Total Refund

Total refund - Response by the API:

{
  "status": true,
  "code": 0,
  "data": {
    "paymentOrderId": "2e0d250097047b7abf1528fd271dd08cb8bc7b3fb7f51e37b3c8fc5c1eb19ec8",
    "shortCode": "JZ3PLK",
    "currencyCode": "EUR",
    "amount": 18400,
    "merchantId": "282682dd6b19c81ee7d6b3322505ebe20e03467c0a6dac129c2206e5202ba375",
    "concept": "Oxford Shoes - Spanish Leather",
    "reference": "OXF-3479",
    "status": "REFUNDED",
    "currentStatus": {},
    "creationDate": 1454490217151
  }
}

Total refund refunds the entire amount paid in a single request. The advantage of this refund is that we do not need to know the amount paid initially, as we refund the total amount at one time.

Url of the request:

PUT {mymoidServerUrl}/pay/order/refund/{paymentOrderId}

You can see examples for both types of refunds aside.

List Payment Orders

Response by the API:

{
  "status": true,
  "code": 0,
  "data": {
    "pagination": {
      "pageNumber": 1,
      "totalPages": 30,
      "elementsPerPage": 5,
      "totalElements": 149
    },
    "elements": [
      {
        "applicationId": "6f029909c4ee51f94f26d050f7b77bac1df993e30b4b288f8bd8b4a60ee7d759",
        "paymentOrderId": "2e0d250097047b7abf1528fd271dd08cb8bc7b3fb7f51e37b3c8fc5c1eb19ec8",
        "shortCode": "JZ3PLK",
        "currencyCode": "EUR",
        "amount": 18400,
        "merchantId": "282682dd6b19c81ee7d6b3322505ebe20e03467c0a6dac129c2206e5202ba375",
        "concept": "Oxford Shoes - Spanish Leather",
        "reference": "OXF-3479",
        "status": "AVAILABLE",
        "creationDate": "2017-04-04T15:06:07+00:00",
        "merchant": {}
      },
      {
        "applicationId": "6f029909c4ee51f94f26d050f7b77bac1df993e30b4b288f8bd8b4a60ee7d759",
        "paymentOrderId": "0b6b459e68aeed8d9c8e734d2acce216b3ab58220dd4d465b6501947875a6e44",
        "shortCode": "Y4LQ2K",
        "currencyCode": "EUR",
        "amount": 28995,
        "merchantId": "282682dd6b19c81ee7d6b3322505ebe20e03467c0a6dac129c2206e5202ba375",
        "concept": "Boss Shoes - Manhattan",
        "reference": "BOS-7281",
        "status": "AVAILABLE",
        "creationDate": "2017-03-14T15:24:27+00:00",
        "merchant": {}
      },
      {
        "applicationId": "6f029909c4ee51f94f26d050f7b77bac1df993e30b4b288f8bd8b4a60ee7d759",
        "paymentOrderId": "d95b48d7a3e03f6c1235cbc953d1ab305d45dc4c2d59816388515c9a8d30cec6",
        "shortCode": "NY1HJ1",
        "currencyCode": "EUR",
        "amount": 12995,
        "merchantId": "282682dd6b19c81ee7d6b3322505ebe20e03467c0a6dac129c2206e5202ba375",
        "concept": "Base London Shoes - TURNER",
        "reference": "BS-6632",
        "status": "PAID",
        "creationDate": "2017-02-15T08:31:45+00:00",
        "merchant": {}
      },
      {
        "applicationId": "6f029909c4ee51f94f26d050f7b77bac1df993e30b4b288f8bd8b4a60ee7d759",
        "paymentOrderId": "a56fe7e4733d07767c0e67839ece94e80d26c7cfd7b63e313344daba95e12ac8",
        "shortCode": "HRP31Z",
        "currencyCode": "EUR",
        "amount": 38495,
        "merchantId": "282682dd6b19c81ee7d6b3322505ebe20e03467c0a6dac129c2206e5202ba375",
        "concept": "Franceschetti Shoes - Philemon Derby",
        "reference": "FRA-89910",
        "status": "PAID",
        "creationDate": "2017-02-09T09:12:56+00:00",
        "merchant": {}
      },
      {
        "applicationId": "6f029909c4ee51f94f26d050f7b77bac1df993e30b4b288f8bd8b4a60ee7d759",
        "paymentOrderId": "ad9367a8361e31e26624c570a477c355f166ae5f79634daacf9edee6d219e0ef",
        "shortCode": "34RGJR",
        "currencyCode": "EUR",
        "amount": 4245,
        "merchantId": "282682dd6b19c81ee7d6b3322505ebe20e03467c0a6dac129c2206e5202ba375",
        "concept": "Pier One Shoes - Dressapp",
        "reference": "PO-0037",
        "status": "EXPIRED",
        "creationDate": "2016-12-20T12:20:24+00:00",
        "merchant": {}
      }
    ]
  }
}

Through the following request you can get a list of Payment Orders created by the merchant:

GET {mymoidServerUrl}/pay/order/merchant/list

Parameters

This request shows a paginated list of Payment Orders created by the merchant with their corresponding information. To facilitate the search task, a series of parameters have been arranged that are described below:

Parameter Format Description
page_size Integer pageSizeParam
page Integer pageNumberParam
from ISO 8601 dateFromParam
to ISO 8601 dateToParam
order_by Field name  orderFieldParam
sort_order asc / desc orderParam

Example Request

{mymoidServerUrl}/pay/order/merchant/list?page_size=10&page=1&from=2016-02-01T22:00:00%2B00:00&to=2016-02-23T22:00:00%2B00:00&order_by=creationDate&sort_order=desc

Payment Order Receipt

Response by the API:

{
  "status": true,
  "code": 0,
  "data": {
    "paymentOrderId": "3e6876520916376713b4e44e6b0d33617b6281ff9728c1e3af783e2142ea96ed",
    "shortCode": "K3LZGL",
    "concept": "Oxford Shoes - Spanish Leather",
    "creationDate": "2017-11-28T09:10:39+00:00",
    "state": "PARTIALLY_REFUNDED",
    "merchant": {
      "vatNumber": "51551259w",
      "name": "Francisco Vallejo",
      "merchantId": "a63c1c35c746c7be262fa971a80466b1543c7eed39b17eab2256a1b4214522c3"
    },
    "preauthorization": {
      "preauthId": "ddac9dadfc43255fb12e447006d52a4d4209f79a79c3b497153293f61b12b9d7",
      "operationDate": "2017-11-28T09:12:48+00:00",
      "amount": 18400,
      "currency": "EUR",
      "processorName": "Redsys",
      "entityProcessorCode": "223170853",
      "authorisationCode": "980782",
      "transactionCode": "511860368261",
      "paymentOperationType": "PREAUTHORIZATION"
    },
    "payment": {
      "paymentId": "b64c83104e888e3c86d29326d8815ec31785b2b98b4d1d7ffdb90fc98cea8fef",
      "operationDate": "2017-11-28T09:13:57+00:00",
      "amount": 100,
      "currency": "EUR",
      "processorName": "Redsys",
      "entityProcessorCode": "223170853",
      "authorisationCode": "980782",
      "transactionCode": "511860368261",
      "paymentOperationType": "PAYMENT"
    },
    "paymentMethod": {
      "holderName": "John Doe",
      "creditCardType": "VISA",
      "firstNumbers": "454881",
      "lastNumbers": "0003"
    },
    "refunds": [
      {
        "paymentId": "1aa65894f36e84718b40032493259b39a033a060c4d1ab6b9c89add9f751ef8f",
        "operationDate": "2017-11-28T09:14:06+00:00",
        "amount": -1,
        "paymentOperationType": "REFUND"
      }
    ]
  }
}

With this method you can get all the Payment information. To perform this operation you have to send the request detailed below:

GET {mymoidServerUrl}/pay/order/{paymentOrderId}/receipt

Payment Order massive generation

This method will help you to generate several paymentOrders in one request. When a massive order generation request is launched, that request goes through several steps within our platform. This happens because it is an asynchronous process in which the orders are generated outside the usual flow of the platform, to not interfere in the normal operation of the same.

Massive generation statuses

Next we will explain the various states by which a massive generation request can be found:

PENDING: When the user calls the API, sending the payment orders basic information, the request creates a new record with this information that later will be processed by the system.

GENERATED: Indicates that the orders have been processed and generated correctly.

BACKED: The orders have been storage in a single file with the new fields generated (PaymentOrderId and ShortCode) and have been sent to the user’s email with the information of the process and the download link.

ERROR: Whenever there is an error in the process, we will update the registry with the status ERROR.

Massive payment order generation

Example body:

[{
  "currency": "EUR",
  "concept": "Oxford Shoes - Spanish Leather",
  "reference": "OXF-3479",
  "amount": 18400,
  "payType": "PAY",
  "expirationDate":"2017-06-30 19:43:00"
},{
  "currency": "EUR",
  "concept": "Oxford T-Shirt - Spanish Leather",
  "reference": "OXF-1972",
  "amount": 24500,
  "payType": "PAY",
  "expirationDate":"2017-06-30 15:32:00"
},{
  "currency": "EUR",
  "concept": "Oxford Hat - Spanish Leather",
  "reference": "OXF-0029",
  "amount": 13100,
  "payType": "PAY",
  "expirationDate":"2017-06-30 11:45:00"
}]

Response by the API:

{
  "status": true,
  "code": 0,
  "data": {
    "publicId": "5ef6f38f68c8fd47224a6468d7ef6e821256987c590e7d971683dbf5963ce08d",
    "applicationId": "6b576228798bd8ea0a733fc000d3003c5500e5ffcea5baaab344a5a5a4cbe283",
    "createdAt": "2017-06-28 10:39:35",
    "updatedAt": "2017-06-28 10:39:35",
    "operationsCount": 3,
    "processState": "PENDING"
  }
}

In the same way that we generate a payment order, we can make a request that generate the necessary orders in a single step. To do so, we must execute the following request:

POST {mymoidServerUrl}/pay/preorder

When the generation process is end and the requests is in status 'BACKED’, you can find a downloand link where you will find all the payment orders generated in the process.

Massive generation file format:

Concept Reference Amount Currency Expiration Date PaymentOrderId ShortCode

Example file:

Oxford Shoes - Spanish Leather OXF-3479 18400 EUR 30/6/17 19:43 61d57b64002cb33eaf42cdb82912dc05cd56d8023b33cfa920d27a24bf5cffc4 M3J2RR
Oxford T-Shirt - Spanish Leather OXF-1972 24500 EUR 30/6/17 15:32 b7330f8e20bb82798cbde514f67ce760aea31680247fc938747840b18c34235a 4R3LNG
Oxford Hat - Spanish Leather OXF-0029 13100 EUR 30/6/17 11:45 f69019c224191457b77ae4cdebfae1c45918e0e0493124a549f87cb80314bfbe JL4NR2

Check generation status

In order to check the process status of the massive generation you can execute the request detailed below:

POST {mymoidServerUrl}/pay/preorder/{publicId}

Response by the API Pending:

{
  "status": true,
  "code": 0,
  "data": {
    "publicId": "5ef6f38f68c8fd47224a6468d7ef6e821256987c590e7d971683dbf5963ce08d",
    "applicationId": "6b576228798bd8ea0a733fc000d3003c5500e5ffcea5baaab344a5a5a4cbe283",
    "createdAt": "2017-06-28 10:39:35",
    "updatedAt": "2017-06-28 10:39:35",
    "operationsCount": 3,
    "processState": "PENDING"
  }
}

Response by the API Backed:

{
  "status": true,
  "code": 0,
  "data": {
    "link": "https://carga-masiva-test.s3.amazonaws.com/int_dev/files/a63c1c35c746c7be262fa971a80466b1543c7eed39b17eab2256a1b4214522c3/BACKED/6b576228798bd8ea0a733fc000d3003c5500e5ffcea5baaab344a5a5a4cbe283/5ef6f38f68c8fd47224a6468d7ef6e821256987c590e7d971683dbf5963ce08d.csv",
    "publicId": "5ef6f38f68c8fd47224a6468d7ef6e821256987c590e7d971683dbf5963ce08d",
    "applicationId": "6b576228798bd8ea0a733fc000d3003c5500e5ffcea5baaab344a5a5a4cbe283",
    "createdAt": "2017-06-28 10:39:35",
    "updatedAt": "2017-06-28 12:40:01",
    "operationsCount": 3,
    "processState": "BACKED"
  }
}

Payment form

Before using the form you must generate a Payment Order. This Payment Order must be in AVAILABLE status at the time of invoking the form. Within the form it is necessary to enter the data of the Payment method to execute the Payment. Workflow

Personalization

The personalization of the Payment form is based on a series of parameters listed below.

Logo

Colours

Recomended Size

Currently the maximum height size of the form’s content is 702px (on desktop displays) or 450px approx. on mobile portrait displays.

The iframe content has been built responsively, so it will fit to the iframe’s width as the webpage resizes. That’s useful to set the width dynamically based on a percentage or setting it with a css media query.

But, on the other hand, you’ll need to set the height manually considering those limitations described above. It’s highly recommended that you set the iframe’s height with a media query, though

Basic Payment form

To pay a Payment Order we need to enter the card’s data that we are going to use in the Payment Order. This form is available in the following address:

{mymoidServerUrl}/tpv/?p={PaymentOrdershortCode}

with shortCode as the identifier returned when creating the Payment Order.

Once the client enters the card’s details, they will be redirected to the corresponding result screen.

Payment form appearance:

Payment form redirection parameters

Users can be redirected to specific URLs through a continue button once the Payment operation has been finalized and depending on its result. To do so, we have to configure some parameters in the form’s URL, as shown in the following examples.

Example of the url format with the final redirection parameters:

{mymoidServerUrl}/tpv/?p={shortCode}&urlok={URL_OK}&urlko={URL_KO}

Payment form appearance with acepted redirection Payment:

Payment form appearance with rejected redirection Payment:

Payment Method

Payment form to reuse

One of the most interesting possibilities of this function is the capability to store a Payment Method without the need to make any charge on it.

To do so we will create a Payment Order for an amount of 0 EUR (or whatever other currency), then we will load its associated payment form and we will enter into it the payment method.

In this case, no charge is made on the Payment Method entered. It simply validates that its information is correct, as such the form does not show the amount of the Payment Order.

If the Payment Method is valid, the Payment Order will appear as paid and we can reuse it as many times as we want in order to reuse the Payment Method stored.

Payment form appearance

Reuse

The reuse is based on the same functionality as reissue. Its finality is to reuse a Payment Method already registered on our platform through a Payment Order already executed. The main difference with the previous method is that to execute a reuse its necessary to have two Payment Order identifiers, one from an order in AVAILABLE status and another from an order with PAID status.

Workflow

API call

Response by the API:

{
  "status": true,
  "code": 0,
  "data": {
    "paymentOrderId": "a08386cba9b4dd00640ffb0f188de26b45c87812cb43f2e00f30ca73d640968a",
    "shortCode": "HMQZ3P",
    "currencyCode": "EUR",
    "amount": 54821,
    "merchantId": "282682dd6b19c81ee7d6b3322505ebe20e03467c0a6dac129c2206e5202ba375",
    "reference": "MYMOID Reference test",
    "concept": "MYMOID Concept test",
    "status": "PAID",
    "currentStatus": {},
    "expirationCard": "01/18",
    "pan": "454881XXXXXXXX0003",
    "creationDate": 1491218865000,
    "payload": {
      "authorisationCode": "102435"
    }
  }
}

As we mentioned before, you can use the next request in order to reuse a Payment Method:

PUT {mymoidServerUrl}/pay/order/execute/{paymentOrderId}/reuse/{OriginalpaymentOrderId}

This request reuses the Payment Method used to pay the first Payment Order (field: OriginalpaymentOrderId) to pay the Payment Order in AVAILABLE status (field: paymentOrderId).

In order to reuse a Payment Method you have to make sure that you are using the credentials provided with this specific permissions.

You can check the permissions list in the Basic concepts - Application section.

Reference

To use this type of Payment it is necessary to register a Reference in our platform, to which we associate Payment Methods. With the identifiers of the Payment Methods registered we can execute the Payment of our Payment Orders. This kind of integration provides you a mayor control about the Payment Methods.

Workflow

Reference attributtes

Attribute Description
referenceId Identifier of the Reference.
value The value of the Reference. This value can be use to identify our Reference in our system and create a relation between both platforms.
deleted Represents wether the Reference is still active.

Payment method attributtes

Attribute Description
paymentMethodId Payment Method’s identifier.
holderName Payment Method holder’s name.
alias Payment Method’s custom name.
type Payment Method’s type.
defaultPaymentMethod Default Payment Method for the reference.
expirationDate Registered Payment Method’s expiration.
expirationDateStr Registered Payment Method’s expiratio, parsed to ISO 8601.
creditCardType Credit card’s type. This value may be VISA or MASTERCARD.
expired Represent if the Payment Method has expired.
verified Represent if the Payment Method has been verified.
firstNumbers PAN number’s first six numbers.
lastNumbers PAN number’s last four numbers.

Creating a Reference

Example body:

{
  "value" : "ReferenceValueOne"
}

Response by the API:

{
  "status": true,
  "code": 0,
  "data": {
    "referenceId": "e95291552a75cb46b4c14c09d9eabe902f8d458b4fcc26dc70fbbcf6aa76ed40",
    "value": "ReferenceValueOne"
  }
}

To start using our Reference Payment the first step you must make is to create a Reference. To do so, we have to perform the following call to the API:

POST {mymoidServerUrl}/pay/reference

After creating the Reference, you receive a unique identifier for the Reference. This field is used to manage the Payment Methods registered and related to this Reference.

Get merchant Reference

Response by the API:

{
  "status": true,
  "code": 0,
  "data": {
    "referenceId": "e95291552a75cb46b4c14c09d9eabe902f8d458b4fcc26dc70fbbcf6aa76ed40",
    "value": "ReferenceValueOne"
  }
}

After you create your first Reference, you can consult its information through the request detailed below:

GET {mymoidServerUrl}/pay/reference/{ReferenceId}

Getting merchant References

Response by the API:

{
  "status": true,
  "code": 0,
  "data": [
    {
      "referenceId": "e95291552a75cb46b4c14c09d9eabe902f8d458b4fcc26dc70fbbcf6aa76ed40",
      "value": "ReferenceValueOne",
      "deleted": false
    },
    {
      "referenceId": "623cd32a63ffc3a1b1eb7a2a05703d8bb0e91a4bc43759b78633821dd2e3215b",
      "value": "ReferenceValueTwo",
      "deleted": false
    },
    {
      "referenceId": "056c7f7b4fde8349585261bae26fed4992de7314a568bd47b5d7b3bbffdc5e83",
      "value": "ReferenceValueThree",
      "deleted": false
    }
  ]
}

Once you have created all your References you can list them through the following request:

GET {mymoidServerUrl}/pay/reference/merchant/{merchantPublicId}

This list shows you all the active References created for your merchant and their unique identifiers, with which you can interact with the API to obtain information about the Payment Methods registered for each one of them.

Delete merchant Reference

Response by the API:

{
  "status": true,
  "code": 0,
  "data": {
    "message": "Reference successfully deleted."
  }
}

The last operation that you can do about a Reference is to delete it through the following request:

DELETE {mymoidServerUrl}/pay/reference/{ReferenceId}

Add Payment Method to a Reference

Example body:

{
  "holderName": "John Doe",
  "alias": "Testing Card",
  "cardNumber": "4548810000000003",
  "expirationDate": "2020-12-17",
  "cvv": "123"
}

Response by the API:

{
  "status": true,
  "code": 0,
  "data": {
    "holderName": "John Doe",
    "alias": "Testing Card",
    "type": "CREDIT_CARD",
    "defaultPaymentMethod": false,
    "paymentMethodId": "10e78d0f26ca7b2613493e48bb7beb64b465ba7b3f6c0a7c5002ec0adbde9413",
    "expirationDate": 1608163200000,
    "expirationDateStr": "2020-12-17T00:00:00+00:00",
    "creditCardType": "VISA",
    "expired": false,
    "verified": false,
    "firstNumbers": "454881",
    "lastNumbers": "0003"
  }
}

Add Payment Method via API

Once the Reference is created we can assign one or more means of payment for later use. The request necessary to perform this operation will be:

{mymoidServerUrl}/pay/reference/{ReferenceId}/paymentmethod

As you can see aside, after sending the Payment Method data you recibe the Payment Method public information registered in our platform. There you can find the value 'paymentMethodId’. This identifier along with the reference identifier is used to perform a Payment operation.

For security reasons when you register a new Payment Method for a Reference, a verification process begins. In order to validate the Payment Method holder we’ll send an operation to the Payment Method recently added. Once you validate the Payment Method this charge would be refunded.

Each Payment Method registered belongs to a specific Reference. In order to make Payments with these Payment Methods it is necessary to send the Reference owner of the Payment Method.

Please, refer to Verify Reference Payment Method section in order to know how to complete this process.

Verify Reference Payment Method

Response by the API:

{
  "status": true,
  "code": 0,
  "data": {
    "message": "Payment method successfully verified."
  }
}

As you can find in the section Add Payment Method To a Reference, before starting a payment process the Payment Method registered must be validated. To execute this request you must implement the request detailed below:

PUT {mymoidServerUrl}/pay/reference/{ReferenceId}/paymentmethod/{PaymentMethodId}/verify/{amount}

Notice that this time a field 'amount’ should be added in addition to PaymentMethodId and ReferenceId. This field represents the value in cents of the charge made to the Payment Method.

Here are some examples of the Payment Method validation amount representation:

Charge Amount value
1.15€ 115
0.59€ 59
1.84€ 184
0.45 45

After validating the Reference Payment Method you can refer to Reference payment Execution section to know how to execute the Payment.

Execute a Payment

Response by the API:

{
  "status": true,
  "code": 0,
  "data": {
    "paymentOrderId": "dfc7e53346b155e021da787faa708509bb2f4ad5bfbd8e81768850b12dc20823",
    "shortCode": "JLN3Q2",
    "currencyCode": "EUR",
    "amount": 68463,
    "merchantId": "282682dd6b19c81ee7d6b3322505ebe20e03467c0a6dac129c2206e5202ba375",
    "reference": "MYMOID Reference test",
    "concept": "MYMOID Concept test",
    "status": "PAID",
    "currentStatus": {},
    "creationDate": 1491219465000
  }
}

In order to execute a Reference Payment you can use the next request:

POST {mymoidServerUrl}/pay/reference/order/{paymentOrderId}/paymentmethod/{PaymentMethodId}

Please, to know how to register a Reference and add a Payment Method to it, refer to Reference section.

Get Reference Payment Method

Response by the API:

{
  "status": true,
  "code": 0,
  "data": {
    "holderName": "John Doe",
    "alias": "Testing Card",
    "type": "CREDIT_CARD",
    "defaultPaymentMethod": false,
    "paymentMethodId": "10e78d0f26ca7b2613493e48bb7beb64b465ba7b3f6c0a7c5002ec0adbde9413",
    "expirationDate": 1608163200000,
    "expirationDateStr": "2020-12-17T00:00:00+00:00",
    "creditCardType": "VISA",
    "expired": false,
    "verified": false,
    "firstNumbers": "454881",
    "lastNumbers": "0003"
  }
}

In order to get the public information of the Payment Method you have to execute the next request:

GET {mymoidServerUrl}/pay/reference/{ReferenceId}/paymentmethod/{PaymentMethodId}

This operation will show all the public information registered for a specific PaymentMethodId.

Get all reference Payment Methods

Response by the API:

{
  "status": true,
  "code": 0,
  "data": [
    {
      "holderName": "John Doe",
      "alias": "Testing Card 1",
      "type": "CREDIT_CARD",
      "defaultPaymentMethod": false,
      "paymentMethodType": "CREDIT_CARD",
      "paymentMethodId": "d0d9f1c3c9e976a25cd8b6b311a39ac4a9591d3fd8adc9af3716ad803dbff548",
      "expirationDate": 1608163200000,
      "expirationDateStr": "2020-12-17T00:00:00+00:00",
      "creditCardType": "VISA",
      "verified": true,
      "firstNumbers": "454881",
      "lastNumbers": "0004"
    },
    {
      "holderName": "John Doe",
      "alias": "Testing Card 2",
      "type": "CREDIT_CARD",
      "defaultPaymentMethod": false,
      "paymentMethodType": "CREDIT_CARD",
      "paymentMethodId": "10e78d0f26ca7b2613493e48bb7beb64b465ba7b3f6c0a7c5002ec0adbde9413",
      "expirationDate": 1608163200000,
      "expirationDateStr": "2020-12-17T00:00:00+00:00",
      "creditCardType": "VISA",
      "verified": false,
      "firstNumbers": "454881",
      "lastNumbers": "0003"
    }
  ]
}

With the next method you can retrieve all your Reference Payment Methods information:

GET {mymoidServerUrl}/pay/reference/{ReferenceId}/paymentmethod

As we mentioned before, a single Reference can storage many Payment Methods. With this request you can list all your Payment Methods so that you can get their Payment Methods to manage them.

Update Reference Payment Method

Example body:

{
  "alias" : "newAliasCard"
}

Response by the API:

{
  "status": true,
  "code": 0,
  "data": {
    "holderName": "John Doe",
    "alias": "newAliasCard",
    "type": "CREDIT_CARD",
    "defaultPaymentMethod": false,
    "paymentMethodId": "10e78d0f26ca7b2613493e48bb7beb64b465ba7b3f6c0a7c5002ec0adbde9413",
    "expirationDate": 1608163200000,
    "expirationDateStr": "2020-12-17T00:00:00+00:00",
    "creditCardType": "VISA",
    "expired": false,
    "verified": true,
    "firstNumbers": "454881",
    "lastNumbers": "0003"
  }
}

To achieve this change you have to execute the next request:

PUT {mymoidServerUrl}/pay/reference/{ReferenceId}/paymentmethod/{PaymentMethodId}

The only field that can be modify after adding a Payment Method is the custom name sent in the 'alias’ field as you can see in the section aside.

Delete a Reference Payment Method

Response by the API:

{
  "status": true,
  "code": 0,
  "data": {
    "message": "Payment method successfully deleted."
  }
}

In order to delete a Payment Method linked to a Reference you have to execute the next request:

DELETE {mymoidServerUrl}/pay/reference/{ReferenceId}/paymentmethod/{PaymentMethodId}

API Errors

Mymoid Errors

In this section we will describe Payment errors returned by the API.

Error Code Meaning
Validator.mymoPay.paymentMethodExpired The Payment Method has expired
Validator.mymoPay.genericGatewayError Generic gateway error
Validator.mymoPay.declinedCardError Declined card, please try another
Validator.mymoPay.cardValidationError Card validation error
Validator.mymoPay.temporaryBlockedOrFraudSuspectCardError Card temporary blocked by the issuer bank or fraud suspect
Validator.mymoPay.invalidCvvCodeError Cvv code is not correct
Validator.mymoPay.fraudSuspectCardError Fraud suspect card
Validator.mymoPay.refundNotAllowedError Refund not allowed
Validator.mymoPay.cardBlockedByIssuerBankError Card is blocked by the issuer bank
Validator.mymoPay.securePaymentNotAllowedOnCurrentGatewayError Current gateway does not allow a secure payment
Validator.mymoPay.refundAmountTooHighError Refund amount is too high
Validator.mymoPay.gatewayServiceError Gateway system error. Try in a few minutes

Processor Errors

KO response by the API from Redsys:

{
    "status": false,
    "code": 200,
    "data": [
        {
            "message": "Generic gateway error",
            "code": "Validator.mymoPay.genericGatewayError",
            "processor": {
                "name": "Redsys",
                "errorCode": "190"
            }
        }
    ]
}

KO response by the API from Worldpay:

{
    "status": false,
    "code": 200,
    "data": [
        {
            "message": "Generic gateway error",
            "code": "Validator.mymoPay.genericGatewayError",
            "processor": {
                "name": "Redsys",
                "errorCode": "190"
            }
        }
    ]
}

When you try to execute a payment a transaction between mymoid and the payment processor is made. If this transaction is denial by the processor we will provide you the infomation about the error code we receive from it, included in the “processor” section of the json sent to your system.

Below we provide you with the proceesor documentation where you can find a detailed explanation about each error code:

Woldpay error documentation. You can find all the errors descriptions availables under the label “ISO 8583 response codes”.

Redsys error documentation. On page 22 you can find a detailed explanation about redsys errors (Only spanish).

Notifications

In this section we will describe notifications sent from MYMOID to merchants. We have two kinds of notifications: email and callback. The email notification sends information once a payment is made using MYMOID platform. The callback notification gives merchant information about a payment operation even if it has failed. As the email notification is enough descriptive by itself, we are going to describe more in detail the callback notification below.

 Callback

Example of a successfull payment callback:

{
   "user":{
      "publicId": "anonymous",
      "paymentMethod":{
         "pan": "454881XXXXXX0004",
         "expirationDate": "12/20",
         "holderName": "John Doe"
      }
   },
   "paymentOrder":{
      "paymentOrderId": "982782aedde3956658a97886299743e9a8492b311abfef984fdd054c8ef31cf6",
      "concept": "Oxford Shoes - Spanish Leather",
      "currency": "EUR",
      "amount": 18400,
      "status": "PAID",
      "updatedAt": 1465315778000,
      "reference": "OXF-3479"
   },
   "application":{
      "id": "6f88f5d7f3eab7cf40b55b353a21af55ab199f5868cdcebf9b9c7f4639652c56",
      "name": "merchant_app"
   },
   "signature": "RQIqiHzECBoBTSWRwLmIO/+OHa6AhN2zh33WeObXZhahO8NFMNFol+TxzAPnlp7f3o5XERdY8+N+Xu2iUn6QLT3mwl2x0yHoNJrRSVt74w2vVJsS7Ns8gHctxSNRmGrCI9EmmcDQrl6pe/fkuqba4tBEApZZZCd0WAuZWvLwGYyI/e0satDi7uJcnz0QKpm3jkpvmPEvfKUthSP5isSmnwHQYFcCWtkmLS1+YzZrZKHlErSt3HhIEwbWxt7YO5tO8UbnECtSO0fvjx9I6kW3JGGhn3v1+NSrijEnhiFpKT/RDqlUiuu4vP7Z3bwE4eecMCd7lKCmohJktPbSwMXQSw=="
}

Example of a failed payment callback:

{
   "user":{
      "publicId": "anonymous",
      "paymentMethod":{
         "pan": "454881XXXXXX0113",
         "expirationDate": "12/20",
         "holderName": "John Doe"
      }
   },
   "paymentOrder":{
      "paymentOrderId": "982782aedde3956658a97886299743e9a8492b311abfef984fdd054c8ef31cf6",
      "concept": "Oxford Shoes - Spanish Leather",
      "currency":"EUR",
      "amount": 18400,
      "status": "AVAILABLE",
      "updatedAt": 1465315494000,
      "reference": "OXF-3479"
   },
   "application":{
      "id": "6f88f5d7f3eab7cf40b55b353a21af55ab199f5868cdcebf9b9c7f4639652c56",
      "name": "merchant_app"
   },
   "error":{
      "message": "Invalid card number",
      "code": "Validator.invalidCardNumber"
   },
   "signature": "o+U3xVYTycAP/Rr3GxKSFm4xTRO+V/yEtCsmbLr36Trz65bZNBVFkRgYV9DJwLBrRR6CTvzyGigWNQT8BIUwIa7sDdHj8MyboaH7ZbO6ZgWZItjI1cLTT7t99H310RGNshYFvoeAkSd9q3IFp8ID5KS6vJumkXziSBcKl0BphXKuBitgrWyya7rg7sNshG6DjByypxmjyJ4EUsPG8MWj3tqHPMOnNRiuSMMX9f9DgaYyCjBQdetKjQY0E8afRjADgatUhS8PZLUzRdRAJqA/bHGnz5YApfp/GpwmqzdRg0SI8LutXlMRkJIafk8+Ni1KJwd7RWyW1SmHcPwXqhBJrA=="
}

After making a payment attempt, MYMOID creates a callback request to Merchant’s callback URL. Callback messages contain payment related information and their sent event if the payment process fails. To ensure callback authenticity, MYMOID applies an electronic sign process to the most important fields of the message. Merchant can use the method described below for ensuring callback origin.

 Signing process

MYMOID uses a RSA public key scheme for signing callback message content. We apply “SHA-256 signing algorithm with RSA encoding as defined in the ‘OSI Interoperability Workshop’ following PKCS #1 conventions”. Resulting signature is Base64 encoded and included in the callback message under 'signature’ attribute.

Data structure to sign

The callback fields used during the process are updatedAt, userPublicId, paymentOrderId, amount, currency, status and applicationId. You can see an example of the string used to sign below:

{updatedAt=1465315778000, userPublicId=anonymous, paymentOrderId=982782aedde3956658a97886299743e9a8492b311abfef984fdd054c8ef31cf6, amount=2, currency=EUR, status=PAID, applicationId=6f88f5d7f3eab7cf40b55b353a21af55ab199f5868cdcebf9b9c7f4639652c56}

You could ask for sandbox and production certificates in order to ensure callbacks authenticity.

Signature verification

Once you have the corresponding certificate, you have to use MYMOID’s public key included inside. You can extract the public key via console using the following command:

openssl x509 -pubkey -noout -in ‘CERTFICATE’ > ‘PUBLIC_KEY’

For content verification simply apply the following steps using the public key extracted above:

A) Convert the signature received on the callback from Base64 to binary:

Echo –n “SIGNATURE_RAW” | base64 --decode > “SIGNATURE_FILE“

Example using aside successful callback message:

echo -n "RQIqiHzECBoBTSWRwLmIO/+OHa6AhN2zh33WeObXZhahO8NFMNFol+TxzAPnlp7f3o5XERdY8+N+Xu2iUn6QLT3mwl2x0yHoNJrRSVt74w2vVJsS7Ns8gHctxSNRmGrCI9EmmcDQrl6pe/fkuqba4tBEApZZZCd0WAuZWvLwGYyI/e0satDi7uJcnz0QKpm3jkpvmPEvfKUthSP5isSmnwHQYFcCWtkmLS1+YzZrZKHlErSt3HhIEwbWxt7YO5tO8UbnECtSO0fvjx9I6kW3JGGhn3v1+NSrijEnhiFpKT/RDqlUiuu4vP7Z3bwE4eecMCd7lKCmohJktPbSwMXQSw==" | base64 --decode > signature-1.sign

B) Check the signature extracted previously obtained, using the certificate’s public key and the base string received in the callback:

Echo –n “BASE_STRING” | openssl dgst –sha256 –verify “PUBLIC_KEY” --signature “SIGNATURE_FILE”

Example using aside successful callback message:

echo –n "{updatedAt=1465315778000, userPublicId=anonymous, paymentOrderId=982782aedde3956658a97886299743e9a8492b311abfef984fdd054c8ef31cf6, amount=2, currency=EUR, status=PAID, applicationId=6f88f5d7f3eab7cf40b55b353a21af55ab199f5868cdcebf9b9c7f4639652c56} | openssl dgst -sha256 -verify pubkey.pem -signature signature-1.sign