Release notes

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
  • Updated transaction details for cancel and refund transactions
  • Enabled pre-auth menu and transaction types
  • Automated push notification to endpoints
  • Support of P2PE for PPaaS Global Reference Application for Axium
  • PODS scalability enhancements
  • 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.

PODS scalability enhancements

PPaaS On-Device Service (PODS) for Android and Tetra and the PPaaS script companion include several improvements allowing software using PODS to support new PPaaS-enabled cloud services (e.g., a new APM service). This is achieved without any code changes or updates to the PPaaS script.

The significant enhancements are as follows:

  • Retrieving a list of activated services and related service domains: A new PODS API is introduced to fetch a list of activated services, their associated SDs, and use cases. This API mirrors the information available through the PPaaS portal or other APIs. The existing PODS API, which returns a service domain as a service, will be deprecated for compatibility purposes.
  • PPaaS script baseline versioning: The PPaaS script now contains all the data needed to support all the current PODS functionality, regardless of the customer configuration.
  • Dynamic service menus: This feature enables the dynamic addition of new menu entries (e.g., APM schemes) to the orchestrator app and the PPaaS Global Reference Application (PGRA). When a new APM scheme is introduced and activated in the PPaaS cloud, it automatically reflects as a new menu entry in the orchestrator app and PGRA without changing any line of code.

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.

Configuration CategoryConfigurations
Card Delivery OptionsSMS
Card Delivery OptionsEmail
Card Delivery OptionsQR Code
Card Delivery OptionsPhysical card
Card TypesGift card
Card TypesRefund card

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 lifecycle 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.

A sample telecollecte receipt (end of day for France) on the portal

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.

Status update on the terminal reconciliation report

Note: This implementation is specific to France.

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:

  • Unique point of entry into the reporting module: 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
Note: This configuration is loaded in the digital receipt service only and not at the core mailer level.

Digital receipt service

Note: This implementation is only specific to the region, France.
  • 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

Note: This implementation is only specific to the region, India.
  • 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.
  • 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. .