Version 1.1.1

About this release

This patch release includes new features and UX/UI design improvements. For complete information about the corresponding release version, see the release summary.

The version hierarchy has been updated since the release 4.0, and future release versions may increment from the current release version.

Release summary for version 1.1.1

What’s new in this release

Core Cloud Platform

Service configuration changes are now possible at merchant and device level before the service is active, and before physical device is attached.

Manage 360

Parameters are now always sent to terminals when activating or upgrading a Device Application service - in the same call as the application binary.

Fixes in this release

Core Cloud Platform

• On the Physical Devices list page, when the user selects to display the last result the page navigation is disabled. This issue has been fixed, and the pagination works properly with all results on each page and the user is able to navigate to previous pages.

• On the Payment Devices list page,

  • the list may not display according to the set filter. This issue has been fixed, and the devices view displays the list of devices according to the selected view.

  • the list view may not display the payment device-related data and display null field data. This issue has been fixed, and the device list view displays the payment related data as expected.

Release summary for version 1.1.0

In a nutshell, the release version 1.1.0 includes the following features:

UX/UI enhancements

• Client portal navigation - Improved the portal’s navigation system. Also enhanced the visual hierarchy, styles, and layouts for readability, content hierarchy within the pages, and overall aesthetic balance.

• Keypad changes on the payment device for clear key separation and user accuracy - Improved keypad design for the payment terminals (PGRA) aimed at reducing transaction declines due to input errors.

• Enhanced styles and layout.

Core Cloud Platform

• Creating merchant segments and assigning scope to users - Introduced segments to apply rules to merchants based on multiple merchant criteria.

• Unified merchant details - Unified merchant details are integrated into a single window view to manage transactions, update details, oversee operations, and so on.

• Redesigned Developer Portal for an improved developer experience.

• Support for Tetra models and bulk import of devices.

Manage 360

• Service Provider can create Device Application services - An entity onboarded as a service provider, can now create their own service in the Device Application service domain on the Service Provider portal.

• Device properties with real-time information.

• Screen Share service - Enabled the “Screen Share” option with Core Device Management service subscription to place a remote screen share request of an online device.

• Remote Key Injection services - Remote Key Injection (RKI) service is introduced to support Triple Data Encryption Standard (3DES) keys via the Classic Remote Key Injection service and Advanced Encryption Standard (AES) keys via the AES remote key injection service.

• Device Management supports Tetra devices.

• Devices detach notifications to manage device cleaning before the next assignment.

Digital Receipts & Commerce services

• APM service domain API and SPI improvement - Improved Application Programming Interface (API) and Service Provider Interface (SPI) of the Alternative Payment Method (APM) service domain to ensure the consistency of the transaction status for payment, cancellation, and refund.

• CLO service domain - Enroll a consumer in-store and online to start earning loyalty rewards.

• Digital receipt - New service from Receipt Hero under the digital receipt service domain. Consumers can enroll to save the digital receipt option through SMS and email for future purchases.

Data & Reporting

• Device management reports - Support for Service Activation and Device Activity Audit Log reports for device management.

• Downloadable payment device reports - Support for downloadable payment device report from the Payment Devices page.

Endpoints

• Internationalization of endpoint deliverables - Enhanced localization in the Orchestrator App, PPaaS Global Reference Application (PGRA), PPaaS OnDevice Service (PODS) on Tetra and Axium platforms, beginning with the introduction of Spanish and French language support.

• Text-based receipts at the endpoint.

Cloud Connector

• Cloud Connector solution for secured connection of the PED and ECR/POS.

Feature description

Client portal navigation

The client portal’s navigation has been improved to be more intuitive, consistent, and adaptable.

Enhancements and changes The improvements include:

• Easier content discovery using the main navigation.

• Better user guidance when accessing content, features, and interacting with the product.

• Better adaptation to include new content and features.

The release changes include:

• A second level to the main menu is added, this can be accessed by expanding the main menu.

• The second-level entries are relocated from tabs to the two-level main menu, for example, Payment devices, Point of sales, and Physical devices are now nested under Devices in the main navigation menu. Note that the tab-based navigation is only used to organize contents in detailed views; for example, information about a specific merchant is organized in tabs named “Overview”, “Services”, and “Stores”.

• A clear description has been added to the first-level page title.

• The clickable breadcrumb in the header consistently indicates the level in the hierarchy of the page viewed and allows the user to go up a level.

Keypad changes on the payment device for clear key separation and user accuracy

This release introduced an improved keypad design for the payment terminals (PGRA), specifically aimed at reducing transaction declines due to input errors. Accessibility is enhanced: the text color of keys and buttons is more contrasted, and the font size is increased for number keys. The new keypad design has been integrated with the existing terminal software, which renders a new layout for clearer key separation and enhanced user accuracy. The same layout will be used in the new design system.

Enhanced styles and layout

The styles and layout applied to the portal are modified to enhance readability, content hierarchy within the pages, and overall aesthetic balance.

Enhancements and changes The release changes include:

• A new typeface is used for displays, headlines, and titles; and reviewed the font sizes.

• Updated the iconography and pictography for more consistency with the visual design.

• Modified spacing to create a cohesive and harmonious layout. While still airy, the use of space is optimized.

• Applied shadows to specific components to help create a sense of hierarchy, order, and spatial relationships between different components. This is also used as a visual cue for some interactive elements.

Creating merchant segments and assigning scope to users

This release introduces a feature that enables the merchant aggregator to assign a subset of his/ her merchant universe to the contractors, ensuring a seamless and organized workflow.

Merchant users and scope

Segments enable the merchant aggregator organization to categorize merchants based on multiple criteria using various rules. These rules consist of different logical operators that can be applied to merchant attributes such as Merchant Name, Merchant City, Assigned Config Profile Name, and more.

The result is a filtered list of merchants based on the defined set of rules within specific segments, which can then be assigned to users to define their scope. This newly created segment can be associated with any user, except the MA admin. The defined segments can also be edited or deleted as needed.

The multiple contractors associated with the clients can be onboarded as users under the merchant aggregator’s organization and the MA admin user can further assign a scope (subset of his merchants) to the users for limited access based on their agreement.

New roles created to support the functionality

To support the feature, the following three roles have been added to the existing ones. The roles are briefly explained below:

• User Management Admin: This user role includes an exclusive privilege to create new users within their hierarchy.

• Manager/Sub_org Admin: This role enjoys the full suite of features available to the merchant aggregator organization’s admin user. However, to maintain precision and control, access to specific sections like Pricing, Subscriptions, and Billing are restricted.

• Merchant Manager: This role empowers the user to take all actions on the Merchants, Stores, and Devices assigned to him/her.

Figure 1: List of roles available in the Client portal

Unified merchant details

To offer an enhanced customer experience, the client portal is now navigation-friendly and more efficient. The merchant details have been conveniently consolidated into one user-friendly tab; this avoids hopping between sections. Right from managing transactions, updating details, or overseeing operations, it’s all seamlessly integrated in a single window for a smoother workflow.

The user can navigate through the consolidated details of the selected merchant. Upon accessing the merchant in the client portal, the user will land on the consolidated page, offering a comprehensive view of the merchant’s information.

Figure 2: Comprehensive view of the merchant’s details

The key sections of the comprehensive view are: Overview, Dashboard, and Contact.

Sections on top: Overview, Services, and Stores

• Overview: Access the merchant’s details and demographic information as currently available in the client portal.

• Services: Access existing information about the services subscribed with the following details: Service Name, Service Domain, Short description of the service, Package details, and Status. Upon selection of a particular service, the user can take the required actions pertaining to configuration and activation.

• Stores: View all stores associated with the selected merchant and can also add new stores as required.

Dashboard

• Devices: View the total number of payment devices linked to the merchant. Click the quick link to open a new tab that allows role-based actions on the devices.

• Users/User Management: Get insights into the total number of users associated with the merchant. Click the quick link to open a new tab for role-based actions on users.

• Transactions: Track the total number of transactions for the selected merchant on the current date. Click the quick link to open a new tab for role-based actions on transactions.

• Tasks: Monitor the total number of tasks in progress for the merchant. Click the quick link to open a new tab for role-based actions on these tasks.

Contact

View the merchant’s contact person’s name, email, and contact details entered during merchant provisioning. Modify and update the existing contact details, as required.

Redesigned Developer Portal for an improved developer experience

Enhancements and changes The developer portal has been updated to improve navigation and the structure of content. The changes include:

• New homepage: Provides an overview of the API solutions and quick access to more content and resources.

• Navigation: Changes include a new vertical menu in the left-hand panel, multiple menu layers, and a table of contents indicated by breadcrumbs.

• New API explorer: Helps developers see all the APIs available at a glance and on one page.

• New visual components: Technical content is presented with new components for alerts, notes, cautions, and consistent styling for sequence diagrams.

Support for Tetra models and bulk import of devices

In this release, the Tetra models are now properly supported on the platform. Instead of having all Ingenico Tetra devices referenced under “Tetra” as model, the model will be filled with the model referenced during the provisioning phase (via APIs, bulk imports, or unitary via the portal).

For example, a Move/5000 terminal model will have this model properly filled. The bulk import functionality is now compatible with all the device manufacturers and device models supported on the platform, earlier, it was limited to Ingenico terminals.

Device Management and Device Application Service Domains

Features in this section require subscription to Core Device Management service.

Service Provider can create Device Application services

In the Service Provider portal, when an entity is onboarded to Manage 360 as a Service Provider, the service provider can now create their own service in the Device Application service domain.

Once the service is created and approved by the tenant, it is available in the Client portal’s subscription catalog. The Service Provider can then add subsequent versions of his Device Application service. Those are then automatically available for deployment to the client that subscribes to them.

Figure 3: Device application configuration in the Service Provider portal

Device properties with real-time information

If the terminal has the required configuration, and after a first synchronization call with the server, then real-time device properties are displayed, which include:

• Online / Offline

• Global Positioning System (GPS) location

• Battery level and status / Random Access Memory (RAM) usage / Flash memory usage / Central Processing Unit (CPU) usage

• If connected, then the connectivity mean used is displayed along with additional information such as:

  • If using a SIM card, then the SIM provider, and the network provider are displayed.

  • If using Wi-Fi, then the SSID name is displayed.

• Firmware and applications embedded in the terminal.

Limitation: Users of a sub-organization cannot access this functionality.

Figure 4: Comprehensive view of the device properties

Figure 5: Details of the payment device

Screen Share service

If Core Device Management is subscribed, then a Device Fleet Operator user can, from the Payment Device page, remotely request an online device to share its screen and, upon user confirmation on the terminal, navigate through the Android terminal user interface and perform non-sensitive actions.

This requires a minima dxmobile 1.25.3 and the required deny list installed on the device. Please refer to the dxmobile solution documentation about the implementation of the device component.

Limitations This feature is partially delivered - available for pilots / tests only, and not ready for commercialization yet.

• Service “Screen Share” is not available.

• Screen share session can be launched even if terminal is disconnected.

• It is required to click “end session” before closing the browser tab.

• Users of a sub-organization cannot access this functionality.

Figure 6: Connectivity status of the payment device

Figure 7: Payment device connected through the screen share option

Remote Key Injection services

This release manages 360 support with the injection of 3DES and AES cryptographic keys into the payment devices necessary for the processing of payment transactions. It is supported only on Ingenico Axium and Tetra devices. 3DES keys and AES keys are supported via the Classic Remote Key Injection service.

Other improvements

Deactivate a Device Application service now removes it from the Axium devices

• By activating a Device Application service domain service, it triggers a task to push the application package down to the physical devices.

• With this release, by deactivating a Device Application Service domain service, it triggers a task to remove the application from the physical device. That functionality is supported only on Axium devices.

Device Application services now support Tetra packages

• A Device Application service containing a Tetra package in format .zip can now be created.

Device Management supports Tetra devices

• All Tetra terminals–with an SDK containing the TMSCall application can receive Tetra packages from Manage 360.

• The following use cases are not supported: real-time activation of Device Application services / real-time device properties / screen share service.

Devices detach notifications to manage device cleaning before the next assignment

This release introduced precise data handling for merchant aggregators, for cases such as during transitions between merchants.

New functionalities

• Displays an alert on the Client portal: An alert notification is displayed to the Client portal’s user about the offline transaction data when detaching a device.

• Merchant offline data validation: Devices on the endpoint now validate data associated with previous merchants before flushing offline transaction data, preventing data misdirection upon reattachment.

• Enhanced detachment and reattachment process: Streamlined the transition of devices between merchants, ensuring data integrity and reducing confusion.

• Data management update: Implemented a new protocol for handling offline transaction data on the endpoint (PODS), including transactional data and receipts data.

• Offline Data Management: Implemented a new system for handling offline transaction data during device swaps, ensuring data is flushed to the correct merchant.

Limitations

• Push notification data: All push notification data from a merchant will be deleted upon detachment, with no error displayed for this data type.

• Digital receipt and transaction data: Only receipt and transaction data will trigger an error message on the terminal if the device identity does not match during the flushing process.

APM service domain API and SPI improvement

This release would improve the API and SPI of the Alternative Payment Method (APM) service domain to ensure the consistency of the transaction status for payment, cancellation, and refund.

Enhancements and changes API and SPI-specific improvements are as follows:

• Minor changes have been implemented on the labels to clearly state the instructions for each step throughout the user experience flow on the terminal.

• Aligned the statuses of the payment, cancellation, and refund transactions from the terminal to the MA portal.

CLO service domain

This release would establish the service domain of the customer loyalty service. With this service domain, a consumer can enroll in-store and online (or from other partners’ platforms) and let the member card start earning loyalty rewards.

New service There is no new service addition to the Card-Linked-Offer (CLO) service domain. The existing Mobi724 service remains excluded from the CLO service domain until further release due to some incompatible merging functionalities.

New functionalities

• Consumer card enrollment in-store

• Consumer card enrollment online

• Consumer enrollment refusal

• Card tokenization

• Reward earning

Limitations

• Card enrollment occurs through the tokenization service at the service provider level.

• To validate the consumer membership at the loyalty program level, the payment system depends on the membership details from a loyalty service provider.

Digital receipt

New service

Introducing Receipt Hero as a new digital receipt service under the digital receipt (DR) service domain version 2. This release would establish a new service from Receipt Hero under the digital receipt service domain and a new functionality allowing the consumer to enroll to save the digital receipt option for future purchases. The new enrolment function enables a consumer to engage in the automatic selection of digitally receiving a receipt through SMS and email.

New functionalities

• Customer engagement allows a consumer to engage in the auto-selection of digitally receiving a receipt through SMS and email.

• This new function also adds to an existing native digital receipt service by Ingenico.

• Digital receipt from the Client portal can be requested in a PDF or PNG image format, formerly the receipt was available only in PDF and HTML formats.

Process changes regarding onboarding and provisioning

• The onboarding process for the digital receipt service by Receipt Hero requires information from Merchant Aggregator (MA), merchant, store, and device information (both physical and logical devices).

• The merchant VAT number is expected to be provided by the MA or the merchants themselves. This information will be used in receipt generation.

Technical changes

• DR hub has been moved from the native DR service to the service domain hub, allowing multiple service providers under the DR.

• The usage event has been moved from the native DR service to the service domain hub.

• PODS will support digital receipt backward compatibility, while PGRA will support only the latest version of digital receipt in this release.

Limitations

• Consumer card enrolment will happen through the tokenization service at the service provider level for both native DR and DR by Receipt Hero services.

• The consumer enrollment option is available only with the digital receipt via SMS or email. The Quick Response (QR) code is not applicable.

• Digital receipt service by Receipt Hero does not support the QR code option.

• For the non-NAR region, the transaction recorder is a prerequisite to DR. Currently, for the NAR region, the transaction recorder is not used, instead DR is used to store the information. Eventually, every region would require transaction recorder with DR.

• Digital receipt service by Receipt Hero does not support non-card transactions.

Device management reports

New functionality: This release introduces two reports for device management under the Reports module.

• Service Activation: A new report type to show the terminal, application, and service information enabling the history of deployment, activation, and deactivation actions for monitoring and billing objectives. The report is available in the client portal where the data can also be downloaded in .csv file format.

• Device Activity Audit Log: A new report to show the activities that have been performed and taken place on a payment device, including logs of users’ activity.

Downloadable payment device reports

New functionality: This release introduces a downloadable payment device report in .csv file format from the Payment Devices page.

Figure 8: Downloadable report option on the payment devices page

Internationalization of endpoint deliverables

Orchestrator App, PGRA, PODS now support dynamic language content. Both Tetra and Axium platforms are designed to adapt to multiple languages and ensure consistent language use. The use of .p3p files for Tetra and strings.xml for Axium as centralized language resources streamlines the process of updating and managing language packs across different applications.

Limitation: This release focuses on Spanish and French, with other languages to follow.

Text-based receipts at the endpoint

This release introduced text-based receipt functionality in addition to the existing image-based format on Tetra terminals using PODS. This update allows for greater flexibility in receipt generation to suit diverse client needs.

Technical changes

• PODS application update: Integrated new receipt format functionalities into the PODS application on Tetra terminals.

• Endpoint API enhancement: Updated API to support the generation and handling of both text-based and image-based receipts.

Limitation: The configuration for receipt format selection is limited to the terminal level and cannot be remotely managed via the Admin and Control section.

Cloud Connector solution for secured connection of the PED and ECR/POS

In this release, The Cloud Connector solution provides a way to securely connect a PED and an ECR/POS. A cloud connection removes the need for technical know-how for the IP configuration required to establish a local connection in store.

The solution uses secure web sockets to establish a dedicated transport pipe, and it is entirely agnostic to the format of messages sent back and forth. One advantage of that is that a client can easily support a mixed estate of terminals, i.e., those with a local connection and those with a cloud-based connection, simultaneously.

The cloud connector solution is designed to work with the Tetra UPP/USI app, requiring no code changes to the payment application. To learn more, please refer to our online documentation available on the Developer Portal under Endpoint Integrations.

New features in v4.00

About this release

This release includes new PPaaS features and UX/UI design improvements. For complete information about the 4.0 release, see the following release notes:

What's new in this release

Service domain evolution

This release includes the following features:

• Device management

  • Support for OS updates

  • Introduction of a new “Device application” service domain enabling application installation and update within managed devices

• Gift card

  • Gift card service domain has been updated with a new transaction type, reporting, and receipt

• BNPL

  • Card based BNPL service has been introduced with the service provider Splitit

  • BNPL service has been updated with the refund transaction type

• Bank card payment

  • Pre-auth update transaction type has been enhanced to update / increment the blocked amount (pre-auth amount) requested by the merchant

Configuration and provisioning

This release includes the following improvements:

• Configuration profiles are introduced, allowing to have different configurations for different sets of merchants

• Configuration changes and activation actions can now be scheduled

• A new public API is available to attach a physical device to a payment device with only two information: physical device serial number and Payment device reference

UX/UI improvements

This release includes the following UX/UI updates:

• Portals

  • Improved the user experience across reports module

• PPaaS application

  • Improved payment experience for both operators and customers for the Android payment terminals

Device Management

This release introduces integrated device management into the platform. To support this functionality, a Device Management service domain is introduced with Core device management being the first service in this domain.

Device application service domain is introduced to manage device applications.

In this release, only Ingenico Axium terminals are supported for device management-related functionality.

Core device management service

The first functionality that is introduced within the core device management service is the capability to update the Operating System (OS) of the supported devices by setting the target OS version in the parameter of the core device management, in the configuration profile for each relevant device model / or merchant / or device. The OS package is created by the Tenant administrator and made available for PPaaS client for deployment via the configuration profile.

Limitations

• The OS version is only configurable at configuration profile and device level and not yet at merchant level.

• When core device management is enabled, it is required to go to the configuration profile to select an OS version and have then the devices getting their OS updated.

Device Properties

A second functionality is accessing a detailed view of devices. From the Devices menu, select a payment device with a physical device attached. The Info tab displays detailed information on the physical device, such as GPS location, Connectivity information, RAM / Flash and Battery status, Hardware and Software details.

Management of device applications

This release supports the push of applications to devices. For this functionality, Device Application Service Domain has been introduced for the PPaaS Client to push applications developed by Ingenico or for the PPaaS client to push its own applications.

Once device management is subscribed, the platform allows the Tenant administrator and the clients to declare device applications, such as payment applications or any other applications, to be managed by the platform. Each device application is managed on the platform as a service. Inside this service, the user can upload several versions of the same application, provide a description, and specify device model compatibility. When such a service is activated at the merchant or device level, the related application, with the version defined in the configuration profile for each relevant device model / or merchant / or device, is pushed and installed automatically on the attached physical devices.

If the device application is compatible with the platform parameter management or with the TEM (The Estate Manager) parameter management, the parameters of such an application can be managed through the service configuration, like for any other service.

Limitations

• When a device application is enabled, it is required to go to the configuration profile first to select an application version before activating this device application.

• Service deactivation of a Device application does not remove the Device Application from the terminal.

• The application version is only configurable at the configuration profile and device level and not at the merchant level.

Gift card - service domain transaction reporting and receipt

The gift card service domain on gift card transactions and receipt details are updated on the PPaaS Client portal. The PPaaS Client portal displays the transaction details with the masked gift card number.

When the gift card redemption succeeds, the receipt displays the text REDEEMED, for unsuccessful redemption, the receipt displays the text DECLINED.

The PPaaS Client portal displays the gift card redemption transaction as a payment method and the transaction list displays the name of the gift card solution provider’s name, such as Diggecard in the card brand column.

BNPL service enabled with refund transactions

A refund is essentially a return of the purchase transaction done by the consumer at the merchant’s payment device. If a transaction purchase is made by a consumer and the consumer returns the goods or service due to an issue with the same, then the merchant initiates a refund against the returned goods or service. The merchant is debited for the transaction, and the consumer is credited for the same.

The illustration below shows the user journey for the refund transaction.

When the consumer returns the goods or service and asks for the return of the transaction debit, the merchant will initiate a refund request for the transaction by selecting the same from the transaction list. The refund amount can be full or partial, after which the refund will be pushed to Klarna. Refunds can also be done multiple times, up to the total amount of the original transaction.

The refund charge slip will be printed on the terminal and will be available on the Web portal as well. To complete the refund cycle, the merchant account is now debited and credited to Klarna, which in turn refunds it to the consumer.

To subscribe to the refund transaction type, the PPaaS client must enable the transaction type from the PPaaS client portal under the Klarna Service at the time of onboarding. Based on the service activation, the merchants will be enabled with refund functionality.

The payment device or PPaaS Client Portal will display the Refund tab under the transaction list to initiate a refund against the transaction. The merchant can check the original transaction receipt, select the appropriate transaction from the transaction list, and initiate a refund accordingly for the transaction.

For a refund transaction, the refund usage event is logged in PPaaS for the PPaaS client reference.

Limitation: On printing the receipt, the Sale header is not center aligned.

BNPL card-based transaction

Splitit service provider integration is available under the service domain, BNPL. Splitit is a BNPL provider where a card transaction can be paid fully or in ‘x’ number of instalments. The BNPL service domain is modified to enable Splitit as a BNPL card payment service provider in the PPaaS service catalog.

Limitation: For BNPL Splitit transaction, manual entry mode of transaction amount is allowed, this limitation will be fixed in the future release.

Enabling Pre-Auth update as an additional transaction type

Pre-authorization or pre-auth is essentially a temporary hold or block placed by a merchant on a customer’s card that reserves funds for a future payment transaction. During the hold period, the funds are unavailable to the customer; they won’t be able to withdraw them or spend them elsewhere.

Pre-auth update: This feature involves the updating / increment of the blocked amount (pre-auth amount) earlier requested by the merchant.

When a customer avails of additional services at the merchant’s establishment and now the merchant wants to update or increment the initial pre-auth request with the updated amount for the additional services, then the merchant should have an option on the payment device screen to update the amount.

With the pre-auth update, a merchant can update the pre-auth amount, which is greater than the original pre-auth amount, to cover the expenses for the additional services availed by the customer.

Before availing of a pre-auth update or using this feature, the merchant must obtain consent from the customer about creating an additional hold on the customer’s card (if required, other than what has originally been created using the pre-auth feature). This can be covered in the merchant's terms and conditions.

At the time of capturing the pre-auth update transaction, the merchant will send a capture request for the updated amount or the amount less than the updated amount.

Note that the pre-auth or pre-auth update request is valid for a particular period as decided by the acquirer. For example, if an acquirer allows a pre-auth request for 30 days, the merchant has 30 days to capture the pre-auth update transaction from the date of the transaction. After this, the funds will be released back to the customer’s account, if not captured by the merchant.

If the merchant decides to capture an amount less than the updated pre-auth amount, then the differential amount would be automatically released to the customer’s bank account.

If a PPaaS client or a merchant wishes to subscribe to the pre-auth update transaction type, it can be enabled and configure at the service level from the PPaaS client portal at the time of onboarding or later too.

Configuration profiles for payment devices

Configuration profiles are introduced to define different sets of configuration parameter values for service domains / services to different groups of merchants. Configuration profiles are named and are accessible through a new entry in the portal in the 'Services' menu.

A default configuration profile is created automatically by PPaaS and will be assigned by default to each merchant. For existing merchants, default configuration profile will not be applied, the existing values assigned to respective configuration parameter will prevail. You can create new configuration profiles with default values or by duplicating an existing configuration profile.

At merchant creation, either by API or by UX, an existing configuration profile shall be assigned to any merchant that will be used to set the configuration parameters for this merchant and any of its devices. Once created, you can continue to change configuration locally at merchant and device level to apply different values than the ones set initially through the configuration profile.

When assigning a new configuration profile to merchants or changing the values of a configuration file, a task will be automatically created to apply the configuration change up to the device level. This change can happen as soon as possible or be scheduled at a later time.

Warning: For existing customers, the default configuration profile will not be automatically assigned to the existing merchants.

Pushing activation and configuration up to devices

For any change or action in the PPaaS cloud that impacts devices, an event is sent to all the relevant devices for the devices to apply the requested change or execute the action. All these changes or actions are managed as tasks.

Configuration changes and service activations can now be scheduled.

Service activation has been updated to support through the portal, the activation of one or multiple services for multiple merchants.

For a task that has been created by the system upon a service activation/deactivation or by a configuration change, it is now possible to pause, resume, or abort a task that is in progress through the task management page.

Limitation: A service appears as (de)activated before the completion of the (de)activation task. The final result of the operation can be found in the corresponding task.

Reporting enhancement

The reports module includes the following improvements:

General

• Report creation follows a new workflow.

• The automatic reports feature has been replaced by the new Share feature, which is applicable to a few reports only. An extensive share option for all the reports will be implemented in the next release.

• Creating and editing a report takes place in a full window.

• The error field borders turn red to indicate that there is an error in the content.

Report list view

• The reports can now be sorted by report type and not report creation time.

• The search box enables you to search the required report list.

• Hovering over a report displays a gray background to make this property uniform across the portal.

Report details

• The descriptions of the widget labels are clear and concise.

• The report titles are made prominent and display the name of the report as provided by the user at the time of report creation.

• The fonts, font weight, and size in the reports have been made consistent.

Enhanced UX/UI for Android payment devices

Introduced key updates to the Android payment terminal endpoint, aimed at enhancing the UX/UI, to deliver a smoother and more versatile payment experience for both operators and customers across various transaction types. This includes the following improvements:

Digital receipts and APMs

• Digital receipts: A streamlined experience for all customers.

• APMs: Added Klarna BNPL and expanded the QR code payment options (including Klarna, Lyf, Alipay+, and WeChat Pay).

Loyalty CLO and gift card options

• Loyalty Programs: Added support for ValueLink Gift Cards and Mobi724 Loyalty program.

• Gift and refund card: Enhanced the issuance and payment functionalities.

• Pre-authorization: Implemented a more intuitive process.

Enhanced Core Screens

• Brand Visibility: The incorporated logo displays in the menu and feedback screens.

• UI Improvements: Refined 'Choose Payment Method,’ ‘Transactions,’ and ‘Enter Amount’ screens, alongside optimizing interfaces for additional functionalities such as Gratuity and Cashback.

New features in v3.00

About this release

This release includes new PPaaS features and UX/UI design improvements. For complete information about the 3.0 release, see the following release notes:

What's new in this release

This release includes the following features:

• New service provider integration is available for the loyalty service domain

• New service provider integration is available for the digital receipt service domain

• New service domain for configuration, fintech routing

• Updated transaction details for cancel and refund transactions

• PPaaS-TEM single sign-on with PPaaS TEM role management

• Enabled pre-auth menu and transaction types

• Automated push notification to endpoints

• Support of P2PE for PPaaS Global Reference Application for Axium

• Sub Organization module

Configuration and provisioning

This release includes the following improvements:

• Updated the service activation model to control the service lifecycle

• Deprecated the Device Stock capability

API updates

This release includes the following API updates:

• Updated digital service domain with Native Solution SPI

• PODS for Android and Tetra now consists of an API to retrieve the versions of the PODS API and of the PODS binary

UX/UI improvements

This release includes the following UX/UI updates:

• PPaaS device application UX/UI improvements for Android devices

• Updated the documentation portal with cookies management, zoom setting, custom tags, and version traceability

• Improved the user experience across all aspects of Report module

Added Loyalty service provider

The loyalty service domain includes Mobi724 as a loyalty service provider. The dependent service is card tokenization from Ingenico. The consumer enrollment tokenizes the consumer’s card and stores the token for any future use. In-store consumer enrollment can be accepted or rejected via a payment device. Consumer's card is recognized at the loyalty program level through the service provider, Mobi724. The consumer can also get the Loyalty reward earning in-store.

This illustration shows typical consumer enrollment for a non-existing card token. It is important to note that without the card token, the refuse button will not display.

This illustration shows typical consumer enrollment for an existing card token.

Process change regarding onboarding and provisioning: PPaaS Client will be onboarded on the PPaaS platform; after that, the support team will manually export the merchant and store information from the PPaaS admin and control portal and drop the file into the service provider’s SFTP. Note that PPaaS GCO team is involved in manually processing the merchant provisioning so there is a lead time on this.

Limitations:

• The instant earning amount will not be displayed directly on the payment device screen; this information will be calculated from the service provider's side. As the service provider’s reward engine will also check for the eligibility of the recent transaction, it will take certain times to calculate and validate the consumer’s membership status. Once the calculation has finished, the information regarding the recent earnings will be sent directly from the service provider to the registered consumer’s phone number.

• The payment flow will be as if there is no loyalty service involved in the user journey from the payment device; the only difference is when the consumer receives the SMS for earning rewards after the transaction.

• The card tokenization is at the service provider level in GTS; therefore, PPaaS requires calling the service provider in order to recognize the card membership at the loyalty program level.

• The merchant provisioning for Mobi724 is manual due to the lack of an API from the service provider's side. Consequently, the support team will have to export the merchant and store information from the PPaaS admin and control portal and drop the file into the service provider’s SFTP. Please note that any change of address under an existing merchant or store can only be done from the PPaaS client portal to get the change reflected on the merchant provisioning report.

• If an enrolled card is added to the Apple wallet, Google wallet, or Samsung wallet, the card will not be recognized as the same enrolled card PAN. Please ensure that the consumer uses the same physical card that was used at the time of loyalty program enrollment.

Updated transaction details for Cancel and Refund transactions

For cancel or refund transactions that are authorized, the PPaaS payment system is set to handle the scenarios in such a way that the transaction details are available for reporting and receipt purposes.

For cancelled transactions, upon request, the payment system returns the complete status and details of the cancelled or refund transaction.

Digital receipt service domain: ReceiptHero

ReciptHero service provider integration is available under the digital receipt service domain. A new provisioning parameter, merchant VAT, has been introduced as a ReceiptHero parameter for the merchants onboarded through the portals.

Parameter configuration: On clicking the "Configure" button, the "Configuration" tab in the drawer displays the parameters based on the service domain selection. During the onboarding of a service provider, merchant information will be shared with the service provider, and the corresponding configuration will be fetched from the service provider. This configuration will be stored in the PPaaS system. When merchants subscribe to additional services, the configuration will be exposed to the PPaaS system.

Digital receipt proxy generation: To enable digital receipt generation use cases for the clients, through proxies, the digital receipt service domain APIs are connected to the ReceiptHero APIs. The use cases include merchant provisioning, consumer enrollment, and digital receipts.

Updated digital receipt service domain

Native Solution SPI: Updated the interface of native solution to fit SPI.

Endpoint version V2 update for Android and Tetra PGRA/PODS:

• The receipt format is now base-64 png for both consumer and merchant scan, if enabled. 

• Simplified the "Get" call.

• Updates in receipt post: The parameter type is updated to sharingMethod and cardToken is updated to idToken which is present in all cases, except enrollment.

• Updates in receipt send: The parameter cardToken is updated to idToken which is present in all cases, except for enrollment. Added the parameter serviceImplenationId in the post response (in case of resend, this should come from the context API). The parameter serverTransactionId is present in all cases, the parameter type is updated to sharingMethod, and the consumer info object.

API implementation (V1/V2): Enabled V1 and V2 of the digital receipt API, directing them to the new digital receipt hub. Enabled Machine-to-Machine (ECR) account usage in the digital receipt and transaction recorder; here, the token will be an ECR token.

Updated features in the documentation portal

Zoom enhancement - native solution SPI alignment: Updated the native solution's interface to seamlessly integrate with the service provider interface.

Custom API tag display enabler: To enhance clarity and categorize key words, we introduced this feature that displays custom API tags, such as PCI, terminal, and so on.

API catalog updates:

Implemented V2 of APIs to integrate new service providers, version V1 is also supported.  The receipt format is now base-64 png for both consumer and merchant scan, if enabled.

• Simplified the "Get" call.

• Updates in receipt post: The parameter type is updated to sharingMethod and cardToken is updated to idToken which is present in all cases except enrollment.

• Updates in receipt send: The parameter cardToken is updated to idToken which is present in all cases, except for enrollment. Added the parameter serviceImplenationId in the post response (in case of resend, this should come from the context API). The parameter serverTransactionId is present in all cases, the parameter type is updated to sharingMethod, and the consumer info object.

Cookies management: To improve the user's experience in the documentation portal, implemented the cookies for the portal with the user's specific permission.

Version traceability: Implemented version management for content traceability and management.

Deprecated Device Stocks

This deprecated feature impacts the Device Stock capability in the user interface, API, and Bulk Import Templates. In the PPaaS Client portal, the changes are:

• To optimize the users experience, the Device Stock field and its associated Reference No. field from PPaaS Client portal, APIs, and the bulk import templates.

• To improve the accuracy and organization of your device management, a new field Organization Name has been added to the PPaaS Client portal, APIs, and bulk import templates in order to allow the users you to link physical devices to specific organizations.

• When creating physical devices, users will have the option to associate each device with a specific organization, allowing for better organization and resource allocation.

• There are no major changes to the process of adding physical devices under an organization. The device stock and reference id fields are now replaced by Organization name.

Version management in PODS

PPaaS On-Device Service (PODS) for Android and Tetra now consists of an API to retrieve the versions of the PODS API and of the PODS binary.

Enhanced UX/UI of the PPaaS Global Reference Application for Android devices

The UX/UI of the PPaaS Global Reference Application (PGRA) for Android application design has been fully revised for a more state-of-the-art design and to uphold Ingenico's brand identity. It includes the following enhancements:

• Color scheme: To align with Ingenico's brand identity and enhance the visual experience for the users, applied a more accessible and refined version of Ingenico blue as the primary color.

• Fonts: Introduced Gilroy, which contributes to a contemporary aesthetic. Additionally, font sizes have been reviewed to maintain consistency throughout the interface.

• Grids and spacing: The uniform alignment of every component across the screens has been thoughtfully aligned and spaced. This consistent grid and spacing approach ensures a seamless and visually pleasing user journey.

• Pictograms and icons: In a cohesive redesign to achieve greater consistency in the interface, all pictograms and icons have been redesigned. This effort guarantees that visual elements communicate harmoniously.

• Button styles: Redefined and consistent in redefining button styles to ensure a uniform and cohesive design language. This improvement brings clarity and a polished look to interactions.

Support of P2PE for PPaaS Global Reference Application for Axium

The PPaaS Global Reference Application (PGRA) for Ingenico Axium devices now supports now Ingenico P2PE-certified module called Secure Payment Service (SPS), in addition to the Ingenico Payment Core Services (PCS) module. SPS allows customers to reach P2PE domain 2 PCI compliance.

Enabling pre-auth transaction types

Pre-auth flow serves the needs of the merchant when the merchant wants to accept payment details from the customer at the start of the journey but capture the amount only after the delivery of the service or goods has been successfully completed.

This feature allows for an additional transaction type (Pre-auth) on the payment system for existing acquirer integration, which can be replicated to other acquirers as well.

For a PPaaS client or merchant to subscribe to Pre-auth, it must be enabled from the PPaaS client portal at the time of onboarding. Once Pre-auth is enabled from the PPaaS client portal or Admin & Control portal, the option of Pre-auth will be visible to the merchant on the hamburger menu of the payment device.

Pre-auth flow involves the blocking of the transaction amount in the user's account at the start of the service or goods delivery by the merchant. The merchant can capture the amount once the service or goods have been successfully delivered. The merchant can choose to capture any amount less than or equal to the initially blocked amount.

Phases of a Pre-auth payment:

1. Pre-auth request

2. Pre-auth capture (Pre-Auth Completion)

3. Release/Pre-auth cancellation

Pre-auth (full suite enablement): Merchants initiate the pre-auth requests for customers, subsequently capturing these transactions on payment devices.

Pre-auth request and pre-auth capture: The merchant initiates the pre-auth request for the consumer. Now, the merchant needs to capture this transaction on the terminal. The merchant will be able to find the transaction from the transaction list with the help of the transaction type - Pre-auth and date. After locating the transaction, the merchant needs to send it for Capture (the capture amount should not be greater than the initial Pre-auth amount). Once the transaction is captured successfully, the status of the transaction changes to Captured from Pre-auth.

Release / Pre-auth cancellation: This phase involves the reversal of the blocked amount back into the user's account. Release of the blocked amount happens due to any of the three reasons listed here:

1. If the user chooses to cancel the delivery of service or goods before the merchant has captured the blocked amount,

2. If the merchant fails to capture the amount within the stipulated maximum block period, in such a scenario, the release will be automatically generated. 

3. If the merchant captures an amount less than the blocked amount, then the differential amount would be automatically released in the user's bank account.

The merchant can navigate to the transaction list from the main menu (available on the home screen) and then the transaction list to identify the Pre-auth transaction. Once the transaction is identified on the transaction list, the merchant has the option to cancel the transaction. By selecting the  ‘Cancel’ option, the Pre-auth transaction is cancelled.

Reporting UX/UI improvements

To enable the customers to view and navigate their business activity in a clear and understandable manner, improved the user experience across all aspects of reporting.

The improvements include:

• Menu sidebar: Renamed the menu entry from "Reporting" to "Reports" and renamed "Dashboard" to "Home".

• Report list view: Organized reports by creation date as the default setting. Enabled user's selection of preferred report filters. Simplified page entry without the arrow icon. Implemented hover color effect for consistency. Transitioned from list view to card view with accompanying filters. Option to switch between list view and card view.

• Search/filters: Introduced a filter by time period (custom dates, last 6 months, 12 months, etc.). Added start and end date filters for uniformity.

• Call to action - new features: Adding "Delete" and "Copy" buttons for each report (for custom reports only).

• Categorization: Included the creation date and time in the report card. Merged reports and automatic reports.

• User guidance: Concise explanations for actions in the predefined report tab.

• Add/edit report drawer: Added brief descriptions under each section's heading to guide users. Removed irrelevant "currency" dropdown. Automated redirection to "report details" upon saving a report. Standardized error boxes' text and background color.

• Placeholders: Implemented placeholders for report creation fields.

• Report details: Enhanced graph widgets with context indicators. Display a balanced number of visualizations to reduce scrolling. Uniformity in widget title styles.

• Automatic reports, list view: Merged automatic reports and manual reports into a single area. Unified report types while allowing sharing and customization.

• Create/edit automatic report drawer: Streamlined the drawer title and content. Concise guidance during automated report creation. Added "Disactivate" and "Activate" buttons for ease of report management.

Service enablement and activation

The service activation model has been updated to better control the service lifecycle, the management of the services, and the different categories of service parameters.

Service enablement: Service enablement is at the PPaaS Client level, which is a one-time activity per service. For some services, there may be service enablement parameter such as SplitSettlementID in the case of service-x. The PPaaS Client would get these parameters from the service provider outside of PPaaS after executing all the required contracts with the service provider. When received, the PPaaS Client can navigate to the Services menu, select the service, click the Enable button, and then enter the service enablement parameters (if required). Once done, the service would be enabled instantly.

It is mandatory for the PPaaS Client to enable the required service, even if it does not require any enablement parameters.

Service activation: Service activation will happen per the following scenarios:

• Service activation use case 1: Service that is provisioning integrated and does not have service activation [in] parameters.

  • Service activation for existing merchants: By default, the service is activated for all direct merchants, stores, and their devices. Explicit activation is required for indirect merchants that exist under a sub-organization.

  • Service activation for new merchants: By default, the service is activated for all new direct merchants, stores, and their devices. Explicit activation is required for new indirect merchants, stores, and their devices under a sub-organization.

• Service activation use case 2: Service that is provisioning integrated and has service activation [in] parameters.

  • Service activation for existing merchants: Explicit activation is required to be done for both direct and indirect merchants, stores, and devices according to the required service activation [in] parameters.

  • Service activation for new merchants: Explicit activation is required to be done for both new direct and indirect merchants, stores, and devices according to the required service activation [in] parameters.

• Service activation use case 3: Service that is not provisioning integrated and does not have service activation [in] parameters.

  • Service activation for existing merchants: By default, the service is activated for all direct merchants, stores, and their devices. Explicit activation is required for indirect merchants that exist under a sub-organization.

  • Service activation for new merchants: By default, the service is activated for all new direct merchants, stores, and their devices. Explicit activation is required for new indirect merchants, stores, and their devices under a sub-organization.

• Service activation use case 4: Service that is not provisioning integrated and has service activation [in] parameters.

  • Service activation for existing merchants: Explicit activation is required to be done for both direct and indirect merchants, stores, and devices according to the required service activation [in] parameters.

  • Service activation for new merchants: Explicit activation is required for new indirect merchants, stores, and their devices under a sub-organization.

Levels of service activation parameters: Service activation [In] parameters can be at merchant level, store level, device level, or on these three levels.

• In case service activation [In] parameter is only at the merchant level and the service is activated, the service would automatically be activated at existing or new stores and devices.

• In case service activation [In] parameter is at merchant level and store level and the service is activated, the service would automatically be activated for all existing and new devices under existing stores. If there is a new store, the PPaaS Client must provide the store level parameters and activate the service explicitly for the new store; then the store level activation status will be further cascaded to device level.

• In case service activation [In] parameters are at merchant, store and device level, for every new device being added, the PPaaS Client would need to provide the service activation [In] parameters to activate the same.

Service related tasks: For any service being activated at any given level, a unique task will be created to show the status of the service being pushed for activation on the device. Activation may happen at the merchant level, store level, or even device level. A task corresponding to activation gets created irrespective of at which level the PPaaS Client has initiated the service activation.

A task is represented with a unique task ID, its creation date and time, description, and the number of devices it covers, along with the status, which can be running, failed, or completed. Within a given task, a subtask is created that is directly related to communicating the service activation till the device level.

Automated push notification to endpoints

Actions for service activations, deactivations, and configuration updates are now automatically pushed to the endpoints, such as payment devices. These updates can then be directly processed by the apps on the endpoints to dynamically update the list of the services that are activated and the related configuration. The portal also now allows users to track the progress of the execution of actions across devices through the new "Task" entry in the menu.

Sub Organization module

With the introduction of Sub Organization feature, the PPaaS Clients now have the ability to seamlessly onboard their sub-organizations, viz. Independent Software Vendors (ISVs), Multi-level Merchants, Technology Solution Providers (TSPs), and Multi-level Merchant Aggregators. This feature enables the PPaaS Clients access a wide range of services offered through PPaaS, further enhancing your business capabilities. The PPaaS Clients will continue to enjoy the benefits of our existing features while also taking advantage of an exciting new capability. With the latest update, the PPaaS Clients have the ability to create multiple levels of sub-organizations within their hierarchy. This means that PPaaS Clients can effortlessly manage and oversee all the sub-organizations under their umbrella. From user management, provisioning and configuration to transaction details and comprehensive reporting, PPaaS Clients will have complete access and control over every aspect, ensuring a seamless experience across their entire network.

Sub-organizations themselves can now take the reins and create their own hierarchy of sub-organizations. This exciting capability allows them to harness the power of user management, seamless provisioning and configuration, as well as access to transaction insights and comprehensive reporting for all their child organizations.

The goal is to give our clients and their entire network an unparalleled level of control and insight, fostering growth and success at every level. Ensuring clarity and transparency, our commitment remains unwavering. We are thrilled to offer our PPaaS Clients a comprehensive, consolidated report encompassing all its entities and associated usage events within their hierarchies. This means accurate tracking, enabling our clients to stay informed and make informed decisions.

As for the billing process, rest assured that PPaaS will continue to handle billing for its direct clients. However, it is important to note that any commercial engagements beyond the PPaaS Client level will need to be managed by the PPaaS Client independently, outside of the PPaaS framework.

New features in v2.00

About this release

This release includes new PPaaS features and UX/UI design improvements. For complete information about the 2.0 release, see the following release notes:

What's new in this release

This release includes the following features:

• Enabled additional acquirers

• Provisioning integration with service provider, Thune-LyfPay and Thune-WeChat

• Implemented BNPL service domain with Klarna

• Implemented Gift card service domain with Diggecard

• Introduced new payment lifecycle reports such as, Transaction summary report, Transaction summary detailed report, and Refunds report

• Automated PPaaS billing in priority markets and streamlined billing automation between PPaaS, SAP, and the PPaaS billing system

• Introduced new technical receipt for Android and terminal reconciliation such as, End of the day receipt, Terminal reconciliation, and Terminal reconciliation report on portal

• PODS support for PCL

• Introduced default and customized devices tab for payment device views

• Added support for RX7000 and DX4000 on PPaaS

Configuration and provisioning

This release includes the following improvements:

• Updated the Alipay+ service configuration

• Minimized provisioning parameters

API updates

This release includes the following API updates:

• API catalog for Application Management

• Refactored the Transaction Recorder API

• Enhanced the DCC API

UX/UI improvements

This release includes the following UX/UI updates:

• PPaaS device application UX/UI improvements

• Updated the Documentation portal for easy navigation and consistency with PPaaS portal

Application management leverages API catalog

This new feature in our application management system empowers developers to configure a specific scope of APIs for their applications. This enhancement provides you with greater control and flexibility over the APIs you wish to consume. 

Our updated application management system now presents a comprehensive list of all deployed APIs. 

Developers can easily navigate through the list and select the specific APIs they want to consume within their applications. 

Enable additional acquirer

This feature will enable additional acquirers that are available through WLAH.

• Service domain and usage events: It will be on BCPS service domain that will utilize the normal usage events of BCPS service domain. This will enhance the acquirer connections of the platform that are available for routing transactions to the acquirer host supported by WLAH and deemed usable by PPaaS clients.

• Status: Acquiring services provided by the acquirer through WLAH will be available in this release.

Alipay+ service configuration

The Alipay role from ACQP (Acquirer) has been changed to Technical Service Provider (TSP) in the integration between PPaaS and the Alipay+ platform. In the previous release, ACQP integration was used. As a result, the onboarding and information requirements have changed on both the PPaaS and Alipay+ sides.

• Change in existing functionality: Without any changes to the existing functionalities, the merchant aggregators and merchants can continue to perform sales, cancellations, and refunds, and utilize merchant scan and consumer scan functionalities. All the familiar features and processes remain intact. 

• Change in existing process: The primary change lies in the setup of the merchant aggregator on the Alipay+ platform and the onboarding process on PPaaS. The new process requires the complete onboarding of the merchant aggregator on the Alipay+ platform. Subsequently, PPaaS will send a link to the merchant aggregator (referred to as the acquirer in Alipay+ terms) to approve the authorization of PPaaS as a TSP, granting it the ability to process transactions on behalf of the acquirer. 

Limitation: The merchant aggregator identification from Alipay+ will be displayed and editable from the PPaaS Client portal in this release.

Provisioning integration with service provider Thune-LyfPay

To streamline and expedite the onboarding experience, we are transitioning from manual provisioning to an automatic provisioning system. This is available for the service provider LyfPay that PPaaS enables through Thune.

Merchants can perform sales utilizing a merchant scan functionality and make a refund similar to WeChat Pay service by Thunes.

Provisioning integration with service provider Thune-WeChat

To streamline and expedite the onboarding experience, we are transitioning from manual provisioning to an automatic provisioning system. This is available for the service provider WeChat that PPaaS enables through Thune.

Merchant sales can utilize a merchant scan functionality and make a refund.

Creation of a Klarna proxy/adapter under the BNPL service domain

Creation of Klarna Proxy/Adapter under BNPL service domain: This new addition enables an additional service for Klarna as a Merchant of Record (MoR), allowing for a new provisioning and configuration use case.

This update does not impact transaction processing. The purpose of this release is to expand the functionality and capabilities of Klarna as a MoR, providing enhanced provisioning and configuration options.

With the creation of the Klarna Proxy/Adapter, we have enabled an additional use case for Klarna as a MoR. This means that all existing Klarna artifacts and functionalities will remain intact, while we introduce new provisioning and configuration capabilities. This enhancement aims to offer a more flexible and tailored experience when setting up Klarna as a MoR.

BNPL: Klarna E2E completion

We have integrated with Klarna as a BNPL (Buy Now, Pay Later) service provider within our PPaaS platform. This integration opens up new opportunities for our merchant aggregators, allowing them to offer BNPL services by Klarna through their in-store terminals.

Our clients will now have the capability to seamlessly support the BNPL service powered by Klarna through their in-store terminals. This enables merchants to offer Klarna's BNPL options to their customers, enhancing their shopping experience. 

Klarna has been onboarded as a service provider within the PPaaS platform, allowing for seamless integration and utilization by our merchant aggregators.

Klarna's BNPL service is now available to our merchant aggregators. They can leverage this service to offer their customers a convenient and flexible payment solution. 

Gift card service domain - Diggecard Integration OUT Diggecard is the first service provider integration under the new service domain of gift cards.

Change in existing functionality: The new service domain includes the creation of new API/SPI and service domain configuration definition.

Implemented the new service, Gift card service by Diggecard with the following functions:

• Issue a gift card and refund card via QR code, SMS, email, or scanning a physical card.

• Check the gift information by scanning the QR code or manually entering the card number.

• Redeem the gift value by scanning the QR code or manually entering the card number. 

Change in existing process: This is a new process as it is a new service. Merchant aggregator will need to contact Diggecard and get the merchant aggregator identifier from Diggecard to be used during merchant aggregator onboarding on the PPaaS platform. The rest of the merchant provisioning will be automatically done from PPaaS to Diggecard based on the service configuration of that merchant.

Limitations: 

• Currency of the gift card at the time of card issuance and redemption will need to match the currency defined at the merchant level at the time of merchant provisioning. Other currencies apart from that would result in failed transaction processing.

• Gift card redemption receipt will need to be set up with additional information required from the merchant aggregator or merchants, as the gift card number will be masked and only show the last four digits.

• Gift card issuance and redemption transactions will NOT appear on the PPaaS Client portal in this release yet.

Payment life-cycle reports 

This release provides operational transaction reporting, specifically targeting acquirers but also merchant aggregators and merchants. To fulfill acquirer expectations, a series of operational transaction reports are added. 

Transaction summary report: The daily sales volume report is available for both merchants and merchant aggregators and acquirers and lists the daily transaction volume/value for the merchant. The report will have the consolidated value/volume across different payment types.

This feature provides a standard transaction report that will be made available for all users of the platform although customized by role (merchant or merchant aggregator or acquirer) listing the daily transaction volume and values for a merchant. It presents an overview of the daily performance and status of all transactions, which can be further consolidated across different payment types (by bank cards and by alternative payment methods).

Transaction summary detailed report: The settlement details report includes the details of payments that have been settled and paid out to merchants by the merchant aggregator or acquirer. It allows merchants, merchant aggregators, and acquirers to configure and view/subscribe to a daily settlement report so that they can see the settlement status. 

Refunds report: The refunds report shows a list of refunds along with the ability to filter and drill down into the individual refund transactions. It is also represented as a widget that can be added to the home dashboard.

This feature is made available for all users of the listing of the daily refund volume and values for a merchant. It presents an overview of the daily performance and status of all transactions, which can be further consolidated across different payment types (by bank cards and by alternative payment methods). 

Automation of PPaaS billing in priority markets

As a PPaaS client portal user, you will be able to access all invoices generated for you by PPaaS through the My PPaaS > Billing tab.

This section would maintain the history of your last 12 monthly invoices, and the detailed reports corresponding to the devices and usage events would be available within this section that would help to reconcile the invoice amount.

Streamlining billing automation between PPaaS, SAP, and the PPaaS billing system

This development will streamline the billing related automation between PPaaS, SAP, and the PPaaS billing system, resulting in reduced manual effort.

Real-time update to the PPaaS client for any modification done in packages

PPaaS has standardized the offering in terms of package per service domain, i.e., there will be one package for every service domain. As PPaaS grows, the number of services will also grow, and in tandem, our packages will continue to grow as well in terms of the number of services.

As per today's scenario, if any service is added to any existing package, it does not reach the PPaaS clients who are current subscribers to the same package. If they wish to get the newly added service, they will need to unsubscribe and then re-subscribe to the same package.

With this functionality, existing PPaaS clients will enjoy the new services being added to the PPaaS packages without having to go through the hassle of re-subscribing to the same package.

Now, with this functionality, the requirement is to design the packages in such a way that any changes made to them should impact the existing subscribers in real time, which includes the following modifications:

• Name of package

• Description of package

• Modification in the icon

• Addition of a service in a package

• Removal of a service in a package

• Modification in SAP codes

TEM billing (including RKI usage events for automated billing)

Now in PPaaS, we would be able to include the count of RKI usage event count by extracting them from TEM (via a report to be executed within TEM).

This would work in an assisted manner wherein a GCO user would extract a report for a given client from TEM which would comprise of the number of RKI event count along with the type of RKI.

Once extracted, GCO users would feed that count into the PPaaS Admin and Control portal for a given PPaaS client for a given billing month. Once the count is captured, it will become a part of PPaaS automated billing, wherein the billing system will take the count, calculate its billing amount based on its pricing, and make it a part of sales order billing data that goes into SAP.

Excluding items with zero amounts from sales orders

SAP does not allow any item with a zero amount to be injected as a part of a sales order.

This feature brings the following:

• Any item with a calculated value of 0 (zero) does not go to SAP.

• If all the items for a client amounts to 0 (zero), we wouldn't inject a sales order in SAP, and a sales order will not be maintained within our system and should not be a part of a sales order report. If, as per the current situation, we are maintaining such a sales order in our system, in the sales order report it will not carry any sales order ID and the status will be "Never injected."

• In the event that only one item in a sales order amounts to zero, such an item shall never appear in the sales order report.

Minimizing provisioning parameters

This feature minimizes the number of parameters required for provisioning merchants, stores, and devices in PPaaS.

This feature enables the merchant aggregator organization to provision, merchants, stores, and devices in one go, if the merchant aggregator organization has only one store and one device for any given merchant. 

It contains two APIs: (The API specification is available on the Docs portal.)

1. Creation of merchant, store, and device: The API name is merchant-hierarchy. In case information pertaining to physical and logical devices exists, this API can complete the provisioning, which also includes the provisioning of the device mapping.

2. Attaching physical device to a logical device: The API name is attach-device. In case information pertaining to device mapping is not available in the Creation API, this API can be used to do the mapping between physical and logical devices. This occurs once the physical device is delivered to the merchant and is activated by the merchant.

Technical receipt for Android and terminal reconciliation on portal

This feature supports technical receipt as per offline email exchange.

End of the day receipt

Transactions from payment devices are stored at the end of each day, and the information is transferred into PPaaS. The technical receipt provides a summary of those transactions for a specific date.

Terminal reconciliation

While uploading the end-of-day technical receipt to PPaaS, the payment device has the option to attach the transaction list in the same API call, this will automatically launch the terminal reconciliation process for these transactions.  On the reporting page, the merchant can access the terminal reconciliation report and, as with any report, apply the required filter to define the dates or other filter options.

Terminal reconciliation report on portal

This report displays all the transactions that have been shared with the reporting service but are not available on the list sent by the terminal in the end-of-day receipts.  When a transaction is reconciled manually, the user can change its status by editing the terminal reconciliation status section on the transaction details drawer, so it will not appear in the report anymore.

Refactoring the Transaction Recorder API 

Experience digital receipts and earn rewards through our new loyalty CLO functionality. Track your transactions with improved merchant records. We prioritize security by implementing reliable identification systems for all external transactions. Experience these enhanced features for a seamless and secure shopping journey. 

Deprecated this API and moved the two endpoints to other existing APIs.

DCC API enhancements 

DCC API changes include:

• Card currency is optional

• 6-digits BIN is added as supported param to request a rate check  

PODS Support for PCL 

The PPaaS endpoint library, called PODS now supports the Tetra terminals; the Ingenico Payment Communication Layer (PCL) is a protocol that is between the POS/ECR and the payment terminals.

Added support for RX7000 and DX4000 on PPaaS 

This release adds the support for Ingenico Axium RX7000 and DX4000 devices in the PPaaS applications. The Client’s portal user can now provision this hardware into PPaaS for them to run PPaaS services.

PPaaS device application UX/UI improvements 

Android UX/UI improvements

• Improved headings on all screens

• Removed some screen inconsistencies

• Visibility on offline success and all aborted/declined transactions (unsent) in single list

Tetra UX/UI improvement: Visibility on offline success and all aborted/declined transactions (unsent) in single list

Simple and customized devices tab

This release allows the user to create custom views under the Payment devices page. These views can have different columns, filters and sorting options. The user can duplicate an existing view, rename it, update it or delete it.

• Default views will be present for all the users.

• Assigned devices: Lists the payment devices that are attached to physical devices.

• Unassigned devices: Lists the payment devices that are not attached to physical devices.

• All: Lists all the payment devices the user can access.

Documentation portal UX/UI update

This release contains some UX/UI improvements on the user interface (UI) of the Documentation portal to enhance the user experience and align it with the design of the ppaas.com portal.

The user’s navigation is enhanced by updating the left menu and enabling the rollover to the right page or menu section. This update aims to provide a consistent and seamless user interface across our platforms.

The user can now download the API specification from the Documentation portal and click on a new Sign up button for registration and get in touch with the PPaaS teams.

New features in v1.00

About this release

This release includes important stability and performance updates as well as new PPaaS features:

• Paper receipt with customization options for the header and footer 

• Improved visual elements and user-friendly navigational capabilities on reporting pages

• Enabling e-mail address and white labeling for sending digital receipts

• Digital receipts with multi-language support

• Capability to bulk import physical devices from the client portal

Paper receipt decoration (for PGRA users)

• Add and customize the paper receipt: This release provides the options to add and customize the header and footer of the paper receipt. The customization may include merchant information, a logo, and additional information. This configuration can be set only on the tenant portal and is not available on the PPaaS client portal. If PPaaS is set to manage the payment processing, the payment application will display the paper receipt decoration.

• Header customization for merchant information and digital receipt logo in .png file format.

• Merchant information: The tenant portal provides the capability to provide merchant information. The following five text lines are available as configuration fields:

  • Receipt Header Line#1

  • Receipt Header Line#2

  • Receipt Header Line#3

  • Receipt Header Line#4

  • Receipt Header Line#5

• Receipt logo: The tenant portal provides the capability to insert a digital receipt logo in PNG format. Insert the receipt logo above the five lines that are reserved for the merchant details.

• Footer customization: The footer section provides the following two text lines as configuration fields:

  • Receipt Footer Line#1

  • Receipt Footer Line#2

Reporting module UX improvements

The reporting module includes improved visual elements and user-friendly navigational capabilities. These improvisations enable users to gain better insights into their business activities and identify areas for optimization and improvement.

The new enablement in the reporting module includes:

• Reporting module UX improvements: Upon entry into the reporting module, the user will be presented with a homepage/dashboard. The reporting module provides several reports on the homepage/dashboard.

• Manage Widgets option: Users can manage the widgets that appear on the homepage via the Manage Widgets option.

• Pre-built and new reports: The reporting module is accessible via the Reporting menu. This shows a list of pre-built reports and provides the capability to add further reports via the Add Report option.

• Automatic reports: Automatic reporting functionality is available under the Automatic Reports tab, where all automated reports are listed.

• View and download charts: The reports are available offline, SVG, and PNG image formats via the burger menu to the top right of each report widget.

• Report categories: The classification of reporting module into Basic and Advanced has been removed. The improved reporting module provides the core reporting behavior.

The reports can be configured based on the categories Transactions, Average transaction amounts, Merchants, and Terminals.

• Transactions

  • Payment method by percentage

  • Payment method by volume

  • Transactions by time period

  • Transactions by payment service type

  • Transactions by terminal type per payment service

• Average transaction amounts

  • By merchant

  • By payment service type

  • By country

  • By time period

• Merchants

  • Transaction volumes by merchant

  • Transaction volume by country

  • Average transaction value by merchant

• Terminals

  • Active terminals total

  • Active terminals by merchant

  • Active terminals over a specific time period

Digital receipt and white labeling of the e-mail

PPaaS supports white labeling an e-mail address to send the digital receipt e-mails. This can be set up manually by the Tenant Admin.

To setup and white label an e-mail address manually:

1. Add a new configuration template to manage the sender.

2. Merge sender and replyto in coremailer.

   • "senderEmail": { "name": "Sender Email", "description": "email address that we send the email from", "schema": { "type": "string", "format":"email", "default": "[noreply@ppaas.tech|mailto:noreply@ppaas.tech]", } },

3. Configure the following fields:

• sender email

• sender name

• reply-to email

• reply-to name

Digital receipt service

• Plaintext PAN solution for merchant receipt: On the client portal, the merchant user can retrieve the clear PAN for a transaction with his receipt.

• Configurable watermark text on the resent receipts: When the digital receipt is resent, the receipt will display a watermark (for example: DUPLICATA). This watermark text is a configurable element in the digital receipt's centralized configuration.

• Searchable reporting field: A new reporting field for each transaction is implemented. This allows the storage of the CB6 merchant ID. This field is also searchable on the reporting page.

• Merchant-specific technical receipts: New endpoint and a new tab on the merchant portal that provides an option to display merchant-specific technical receipts such as:

  • Request for information receipt

  • End of day receipts / batch upload (EMV, non EMV, and not complete)

  • Preauthorization initiation receipt

  • Additional bill receipt

Bank card payment services

• Enabling storage and transmission of Card holder Name: The Card holder Name is added to the PE database. The card holder name can be transmitted across other services, including Reporting, and Digital Receipts.

• RuPay Certification: PPaaS is certified for the RuPay scheme in India.

• Transaction validation service validation: With this implementation, each transaction can be scanned for various checks, such as velocity checks, that can be performed by the PPaaS client's choice of transaction validation service. For each transaction, PPaaS will invoke the client’s transaction validation API.

• Transaction Status API: A new Transaction status check API is developed and delivered for PPaaS clients to know the transaction status.

Client portal with regrouped device details

All the device-related entries in the client portal have been regrouped under a Devices entry. There is no functional change in managing device stock and physical devices.

MACO configuration is optional

The tenant and/or PPaaS client can activate or deactivate MACO based on the payment applications deployed on the terminal. The PPaaS Merchant Approval COde (MACO) can either be enabled or disabled for PPaaS-based refund and cancel transactions. When MACO is disabled, the payment app(s) has other means to authorize a merchant supervisor to realize such sensitive operations (i.e., refund and cancel) on the terminal.

Bulk import to create multiple physical device entries

The bulk import feature on the PPaaS client portal allows the Merchant Aggregator admin and DFO users to upload multiple entries via bulk upload feature. This is currently capped at 10,000 records in a single upload in .csv file format.

The steps to bulk import physical device entries are:

1. The merchant aggregator admin or the DFO user will be able to download a template with the required import file format to upload multiple device stocks.

2. Access the file and add the received physical device details.

3. Upload the file to PPaaS and a success message will appear on the client portal's upload screen. In the event of an upload failure, the rejection reason is displayed on the client portal and a report highlights the error reasons on the row(s) with defects. Rectify the records and reupload the file.

4. Upon successful upload, the devices will be added to the merchant aggregator’s physical device list.

Register API when creating an application

While creating or modifying an application, PPaaS allows the users to:

• Select a list of API Products: Users can select a list of API products that a client using this application object can call.

• Provide the SPI URL: Users can provide the SPI URL, this is the URL that PPaaS will treat as the service provider's proxy URL; PPaaS will call the SPIs on that URL for the service provider's consumption.

• Select the list of SPI: Users can select the list of SPI, and PPaaS will call the service provider's proxy only for the selected SPI.

Useful links

• Client Portal User Guide: Once you have been authenticated into the portal, navigate to the top-right corner of the page, click the help icon, and select the User Guide option to view the user guide.

• Digital Receipt User Guide: Contact us at PPaaS Support to get the Digital Receipt user guide.

• Endpoint SDK: Please contact your PPaaS point of contact to get the Endpoint SDK files you would need or write us at PPaaS Support.