P4A Payment Infrastructure

From wiki.gpii
Jump to: navigation, search


The secure payment infrastructure undertakes the charging of the assistance services or tools offered through the P4A ecosystem and takes care of the relevant payment through commonly used methods. It includes three subsystems: a) the charging and payment subsystem, which facilitates service suppliers and provides trust to the service consumers b) the micropayment subsystem, which is dedicated to payments of micro amounts c) the user funding subsystem, which allows anonymous users or a third party to outline a desired service and bid for its creation and notify service suppliers/developers to declare whether they intend to create the service.

Target Audience(s)

The target users are service suppliers that want to use the P4All functionality for charging for their services and select from a wide set of charging and billing models. The payment infrastructure will be used also by the end users that consume services.

Potential Applications

P4A payment infrastructure relieves service suppliers from the development of a payment system or interaction with third-party systems, as it facilitates the interaction with third party systems, through the usage of P4All functionality (registration, authentication, authorization and logging). The payment infrastructure also offers innovative functionality in terms of micropayment and crowd-funding through the corresponding subsystems.

The charging and payment subsystem is responsible for the following workflow: (a) usage of services on behalf of the consumer and subsequent charging and notification (b) billing depending on the preferences of the user (c) payment on behalf of the user and notifications This is completed with the retrieval of statistics on behalf of the consumer, the supplier and the administrator as well as the administration of his/her profile on behalf of the user.

In terms of functionality the charging and payment subsystem provides the following:

  • Charging of the services used: Charging is based on end user access information (or other information provided by the end user, in case of physical services) and it uses the charging policy provided by the service provider. The notification of charging (immediately or upon specific periods) is dependent on the preferences of the user.
  • Billing: The system creates the bill for the end user, based primarily upon the service requirements / terms and the preferences of the user. The payment can be related to the usage of services / products by himself or another end user (e..g in case he is a carer).
  • Payment: The end user makes the payment according to the bill that he/she has received.
  • Prepayment : The user disposes an amount to be available for future payments by the user or a third user.
  • Notifications and reports: The (authorized) user can select to be notified, instantaneously or upon a specific period, in a fine-grained fashion for charging, payments and changes in his profile (e.g. associated/sponsored) users.
  • Administration: Administrative interfaces are offered to the service (retrieval of the charging policy, return of charging information), the payment gateways and the notification mechanism.


In order to maximize trust to the payment infrastructure, we plan to integrate web APIs for popular electronic wallets. PayPal is an established solution, available worldwide and as it covers the currently identified needs of the P4All ecosystem, it will be the basis of the Payment subsystem (with charging based on custom functionality provided by the Charging subsystem in collaboration with the service suppliers who provide the charging and pricing policy for their services). The functionality will run through a common browser (no need for extra infrastructure).

Licence Information

The licences accompanying the Payment infrastructure software contain re-distribution friendly directives (Apache, BSD etc.). None of them is proprietary and/or of limited (re)use.

Status, Known Issues & Planned Work

The system is currently in the phase of use case specifications, requirements identification and analysis.

Further Resources

We have defined a list of scenarios for the Charging and Payment subsystem as shown in the following table.

Scenario title Description Task
Scenario 1: Charging and Billing Act 1 - Provision of Service Charging Policy: The Service Provider while registering the service to the payment infrastructure provides the charging policy to be employed. In P4All the following charging policies can be employed (according to DoW requirements and service requirements up to now): (a) flat monthly or daily rate, (b) fee per session (verified after authentication and authorization). The charging policy also specifies whether the charge how it will be aggregated to the bill sent to the user, the acceptable means of payment and the payment deadlines. The credit allowed per user (per paying period) is also specified. More complex charging scenarios, based on service – specific features, are not currently foreseen. If they are to be used, the service provider should provide the related mechanism and provide the charging information to the payment layer. 205.3
Act 2 - User charging: The user accesses and makes use of a P4All service. Due to this usage, charges occur according to the charging policy of the specific service. Charges are persisted in the charging profile of the user, when they occur (or after they are retrieved from the service provider). Information related to each charging includes: the user charged, the service involved, the charged amount (ranging from small amounts, fraction of € to larger ones depending on the credit allowed by the service provider), the date and time of usage, a link to the charging policy. Charges are available for view by the user in almost real –time (unless the service provider has specified other intervals).
Act 3 - User billing: At regular intervals, e.g. once a month or once a week, the user can retrieve the bill related to the charges that have occurred due to the interactions that have been performed by himself or by an authorized (sponsored) user with the P4All system and services. The bill includes the full set of charges in an aggregated manner and as individual records (with the related metadata per charge). The bill specifies the deadline for its payment (depending on the charging policy of the services included).
Act 4 - Viewing and updating of charge settings: The user can set the preferences for charging (frequency of charging, level of details, channel of distribution and notifications). From the viewing point of view, the user can check his charges and payments regarding the full set of services provided by AoD, with the presuppositions that the charging and payments are performed through the payment infrastructure. The records include (a) charging service, (b) date and time, (c) and any metadata regarding the verbose level selected by the user (during service registration).
Act 5 - Billing calibration: This is focused on the rationalization of the charges, especially in cases of multiple service suppliers and consumers and of small charging amounts. In order to limit the interchange fees, an algorithm will minimize the transactions between suppliers and consumers without altering the charges. If, for example, the consumers C1, C2, C3 and C4 have charges towards the suppliers S1, S2, S3 and S4, this functionality sums the charges and, based on the full sum, makes correspondences in order to minimize number of transactions (and fees). Acceptance by both the suppliers and consumers is required for this calibration to take place. Further details will be provided.
Scenario 2: Payment and Pre-payment Act 1 - Payment: After the user has received the bill notification, he can visit the P4All charging and payment web page, review the charging items that compose the bill and finally pay the full or a subset of the amount charged. The payment can be related to the usage of services / products by himself or a sponsored user. P4All offers the typical payment options in co-operation with payment gateways and specifically Paypal. In this case the user is safely connected with PayPal portal. The system offers to store, in an encrypted manner, user details for convenience (upon verification / acceptance). For security reasons this option is de-activated by default. Upon payment the user is notified with email or other means he has selected. 205.3
Act 2 - Pre-payment: The user can reserve an amount to be used for future service usage. This amount reservation has the form of service usage prepayment. This feature allows the selection of the amount, the involved service and users (himself or sponsored users) as well as the expiration of this reservation. Other conditions may apply depending on service characteristics (to be provided, if applicable, by the service providers).
Scenario 3: Notifications and Reporting Act 1 - Charge and Payment notification and report (user): Upon charging and payment the user is notified. Detailed reporting is also provided within the profile in the charging and payment section, describing the charges per service, period, amount and sponsored user. Typical statistical results, such as service with maximum charges or charges evolution in a specific time period (either aggregated or per service) are offered to the user, through the UI. Data export capabilities are also available. 205.3
Act 2 - Charge and Payment notification and report (service provider): Upon the payment on behalf of the user, the system updates the charging and payment records, related to the involved services and notifies the owners of the services (the service providers). The charging and payment information is available to the service providers through the dedicated pages. Typical statistical results, such as service with maximum charges or charges evolution in a specific time period (either aggregated or per service) are offered to the user, through the UI. Data export capabilities are also available.
Act 3 - Charge and Payment report (platform provider): The platform provider has access to the charges and payment performed on behalf of the service providers and the users. Similarly, statistical results, such as service with maximum charges or charges evolution in a specific time period (either aggregated or per service) are offered to the user, through the UI. Data export capabilities are also available.



Related/Alternative Tools

PayPal is currently considered to be the underlying payment infrastructure to be used.

Getting Involved

Code Repository