Card Payment
The Payment API is used to trigger, cancel or refund a payment transaction.
Card-Linked Offer
* CLO API to be consumer by terminals * Features: * The CLO API is used to perform : - clo processing (token comparison against id-token database) - clo member management (enrolment, revocation, retrieve details) * The 'programId' field is used by PPaaS to identify the clo-program by clo-partner - PPaaS programId is unique and share with the partner (partnerProgramId = programId) * A merchant can be affiliated to no one, only one or several clo programs * The 'programId' field can be omitted, in this case, a programId determination logic is applied according to the endpoint either: - PPaaS rejects the request (error, cannot determine what is the programId) - PPaaS selects the default clo program (the one which has been defined as default one) - PPaaS selects the unique clo program (if the merchant is affiliated to only one program) - PPaaS processes to all the merchant affiliated clo programs * The way for handling the 'programId' (programId not specified in the request) is described in each endpoint
Configuration
This API is used to access and update the configuration of PPaaS services.
Digital Receipt
This section contains the SPIs for the digital receipt service domain, endpoints to send a transaction with all its details to a service provider as well as consumer enrollment.
Digital Receipt
This section contains endpoints to Post and retrieve consumer and/or merchant receipt to the digital receipt hub, as well as consumer enrollment in the digital receipt service.
Dynamic Currency Conversion
The DCC service gives consumers from abroad a choice to pay in the local currency or in their own currency.
Fintech Routing
# Fintech API description Features: * The Fintech API is used to connect to fintech provider
Gift Card
The gift card service provider should implement the Gift Card SPI to handle gift card transactions (issuance, activation, redemption, get details)
Gift Card
- The gift card API is used by the terminals and POS devices to perform gift card transactions (issuance, activation, redemption and get details) - The "ppaasProduct" is the service name of gift card provider (ex: happy_card by gift card provider) - For a specific merchant a list of ppaasProduct can be configured - The "ppaasProduct" is used to link a merchant to a giftcard program and a giftcard provider - The "ppaasProduct" field is mandatory
Provisioning
This API exposes the operations performed by the ISS service provider proxies. This document explains the API specifications, that need to be followed by the service providers while creating their proxy. SP need to define the proxy API by following this YAML documentation. ### Definitions - The requests are describing an event related to an entity of the hierarchy. In this section, this entity is called the "*target entity*". - The Service Implementation Definition includes the type of relevant entities or configurations that must be published to the service provider. Entity of these types are called the "*published entities*", for example merchant, store or logical-device. The information sharing service will send requests for the changes occurring to any published entity or above it. ### Example - the merchant profile is updated - the merchant configuration is updated - a merchant has opened a new store - a new logical device is created for the store When the merchant creates a new store and saves it in PPaaS , the service provider proxy will receive the following requests: - "create-store" with a hierarchy going down to the store. When a new logical device is added to the store, request is sent for "create-logical-device". When the existing merchant or store details are updated, the service provider proxy will receive the following request: - "update-merchant" with a hierarchy going down to the logical device if merchant is updated - "update-store" with a hierarchy going down to the logical device if store is updated ### Request Information The request body contains the following information: - the code of the operation - the hierarchy before the operation, from the tenant and down to the published entity - the list of aggregated configurations at the level of the published entity before the operation (if the configurations are relevant for the service provider) - the element modified by the operation: provisioning(an entity), or a configuration - the configurations updated by the event. The request header contains the following information: - a custom header for HMAC, "SpiSignature" - HMAC is a cryptographic method that guarantees the integrity of the message between two parties. The HMAC algorithm consists of a secret key and a hash function. The secret key is a unique piece of information or a string of characters. It is known both by the sender and the receiver of the message. The hash function is a mapping algorithm that converts one sequence to another sequence. - HMAC to be defined for SPI. HMAC = sha512(secret key + request payload + timestamp) - HMAC recommended algorithm - SHA-512 Operation | Code | Modified Element | Comment -------------------------------------|-----------------------------------|-------------------------------------------------------------------|---------------------- creation of a merchant | `create-merchant` | `updatedHierarchy`: the created entity | the previous hierarchy above the target entity before the creation update of a merchant | `update-merchant` | `updatedHierarchy`: the updated entity deletion of a merchant | `delete-merchant` | `updatedHierarchy`: the updated entity creation of a store | `create-store` | `updatedHierarchy`: the created entity | the previous hierarchy above the target entity before the creation update of a store | `update-store` | `updatedHierarchy`: the updated entity deletion of a store | `delete-store` | `updatedHierarchy`: the updated entity creation of a Logical Device | `create-logical-device` | `updatedHierarchy`: the created entity | the previous hierarchy above the target entity before the creation update of a Logical Device | `update-logical-device` | `updatedHierarchy`: the updated entity deletion of a logical device | `delete-logical-device` | `updatedHierarchy`: the updated entity update of configuration | `update-configuration` | `updatedConfiguration`: the new aggregated configuration at the level of the published entity | the previous hierarchy includes the logical device
Provisioning V1
The public section allows the control of the hierarchy on PPaaS from the tenant to the device.
Provisioning V2
The public section allows the control of the hierarchy on PPaaS from the merchant to the device.<br/> In version 2, we have deprecated the concept of Device-Stock and hence, the physical device APIs are impacted with new parent as Organization.
QR Code Payment
The alternative payment method (APM) SPI is used to interface PPaaS and a QR code payment service provider - It handles payment, cancellation and refund transactions - The payment can be carried out in 2 QR payment modes: "consumerScan" or "merchantScan" - Note: cancellation and refund can be done via the payment device or from the portal - WARNING: A successful request (201 or 202 status) doesn't mean that the transaction succeed : - The payment might be rejected in this case the response contains an 'error' object - The 'error' object contains error details
QR Code Payment
The alternative payment method (APM) is used to interface a payment device and PPaaS - It handles payment, cancellation and refund transactions - The payment can be carried out in 2 QR payment modes: "consumerScan" or "merchantScan" - Note: cancellation and refund can be done via the payment device or from the portal - WARNING: A successful request (201 or 202 status) doesn't mean that the transaction succeed : - The payment might be rejected in this case the response contains an 'error' object - The 'error' object contains error details
QR Code Payment Notification
The SPI QR Code Payment APIs for the notification
Reporting
This public section contains endpoints to push transactions to the reporting service with their receipt to retrieve them, to set a comment associated to a transaction to search them massively This private section provides all APIs needed for the portal to work properly. Widgets, column settings APIs It contains automatic report APIs. It contains downloading of a set of transactions as a csv file.
Resources
common resources like currencies, countries, timezones, merchant category codes
Retail API
The Retail API defines operations between the POS and the Payment Device (called POI in Nexo)
Subscription
The Subscription API manages the subscriptions to the services Following action can be performed: - Create a subscription - Approve a subscription request - Delete a subscription request - Catalog for
Tokenization
* The tokenization service is used by an external partner for requesting idToken computation - the idToken is computed for a card number (pan) and belongs to a group
Transaction Recorder
Transaction API to record external payment transactions, and retrieve payment transaction data, loyalty data and associated receipts for transactions processed by PPaaS or externally and recorded in PPaaS
User Management
The user management service provides API to manage the user of the Ppaas solution.