Home > Tech Writers Hub > Knowledge Services Sandbox > Aria Media Publishing Suite > Aria Media and Publishing Suite (AMPS) - Payment Management

Aria Media and Publishing Suite (AMPS) - Payment Management

Overview

The Payment Management component of AMPS provides functionality to handle inbound and outbound payments from end customers through a variety of payment methods such as bank transfer, direct debits, credit cards, etc. Payment Management provides the following major capabilities:

  • Payments – AMPS provide the ability to receive payments from customers through different means, for example direct debit, bank transfers, credit cards, etc. When a payment is received it will be matched to one or more invoices created by AMPS. Handling of underpayments and overpayments are also supported. 
  • Refunds – AMPS provide the functionality to refund money back to the customer, for example when they have paid too much, when they cancel their subscription mid-period, or for simple compensations. Refunds over a certain limit must be approved by authorized CSR staff. 
  • Mandates – for direct debit payments, AMPS provide the functionality to capture these mandates and use them in any subsequent billing. Mandates are usually received from external financial institutions. 

Other functionality may be added in the future as requirements change. 
 

Payment Management 

The Payment Management component consists of the services, reports and sub flows shown in the below diagram.

Payment Management Graphic.jpg

Payment Management Graphic 2.jpg

 

Each of the services, reports, and processes in support of this functionality is described below:

Validate NETS eFaktura file [PaymValNETSeFaktura]

"Validate NETS eFaktura file" is a service that validates a NETS eFaktura file received from the financial institution. If no errors are found, the file is processed. Otherwise the file is rejected, and the financial institution must correct the issue. 

Handle NETS eFaktura file [PaymHndlNETSeFaktura]

"Handle NETS eFaktura file" is a service that processes a validated and accepted NETS eFaktura file received from the financial institution. The file is processed according to the rules. Payments are registered in the system with a call to the register payment sub-flow. 

Validate NETS OCR file [PaymValNETSOCR]

"Validate NETS OCR file" is a service that validates a NETS OCR file received from the financial institution. If no errors are found, the file is processed. Otherwise the file is rejected, and the financial institution must correct the issue.

Handle NETS OCR file [PaymHndlNETSOCR]

"Handle NETS OCR file" is a service that processes a validated and accepted NETS OCR file received from the financial institution. The file is processed according to the rules. Payments are registered in the system with a call to the register payment sub-flow.

Validate VIPPS file [PaymValVIPPS]

"Validate VIPPS file" is a service that validates a VIPPS file received from the financial institution. If no errors are found, the file is processed. Otherwise the file is rejected, and the financial institution must correct the issue.

Handle VIPPS file [PaymHndlVIPPS]

"Handle VIPPS file" is a service that processes a validated and accepted VIPPS file received from the financial institution. The file is processed according to the rules. Payments are registered in the system with a call to the register payment sub-flow.

Process Payment [PaymProcessPayment]

"Process Payment" is a sub-flow that processes received payment requests. The service is used to locate the matching account and invoice and then post the payment against the invoices found and according to the rules configured. 

Process Mandate [PaymProcessMandate]

"Process Mandate" is a sub-flow that processes received mandate requests. The service is used to locate the matching account and then update the payment method according to the rules configured. 

Process Refund [PaymProcessRefund]

"Process Refund" is a sub-flow that processes received refund requests. The service is used to locate the matching account and invoice and then post the refund against the invoices found and according to the rules configured. 

Manage Refund [PaymManageRefund]

"Manage Refund" is a service that is used to create refunds and handle their potential approval depending on the configuration.

Retrieve Refund [PaymRetrieveRefund]

"Retrieve Refund" is a service used to retrieve refunds registered in the system whether they are pending approval or not.  

Collect Payment [PaymCollectPayment]

"Collection Payment" is a service used to collect payment as and when the invoice/receipt is produced by Aria. Primarily used with credit cards handled outside of a Aria developed payment gateway. 

Callback Payment [PaymCallbackPayment]

"Callback Payment" is a service used to process callbacks received from external payment gateways managed by AMPS.

Issue Refund [PaymIssueRefund]

"Issue Refund" is a service used to provide refunds via an AMPS management external payment gateway.

Register Payment Request [PaymRegisterPayRequest]

"Register Payment Request" is a service used to register payment requests to be sent to the external payment gateway in the situation where an Aria account or billing group has not yet been created in AMPS.

Process AMPS Payment Request [PaymAMPSPayRequest]

"Process AMPS Payment Request" is a sub flow used to register payment requests for invoices to be paid via an external payment gateway. After the payment request has been registered it will be transferred to the external payment gateway.

Process Overview

Collection via External Gateway

This section contains a description of the process executed when collecting funds via an external payment gateway like Mobilepay, VIPPS, SPID, etc. The process is used only if the payment option indicates that funds are collected via an external gateway not directly managed by Aria. The figure below shows the overall process of collection via an external gateway. The services (marked in blue) are specific for the external payment gateway and is either developed by Aria or by the client directly. 

Collection via External Gateway Graphic.jpg

The collection process is triggered when "Process AMPS Payment Request [PaymAMPSPayRequest]" has received a request and logged it as a new request in the "AMPS Payment Request" table. The collection process then goes through the following steps:

  1. The "Collect Payment [PaymCollectPayment]" will with regular intervals (usually minutes) and retrieve all new and pending payment requests. Each payment request is processed according to the configuration found for a payment option and variant as found in "Payment Option" table. 
  2. Based on the payment request being processed, "Collect Payment [PaymCollectPayment]" will either issue a "Collect Recurring Payment" or a "Collect One-time Payment" request and send it to the external payment gateway process as identified by the gateway. The request may go to the same process or potentially to different processes. 
  3. Based on the response received from the external payment gateway, the "Collect Payment [PaymCollectPayment]" process may post the payment directly against Aria by invoking the "Process Payment [PaymProcessPayment]". The status of the request is updated in the AMPS Payment Request table. If payment is not immediately collected by the external gateway, the AMPS Payment Request is updated to reflect this as well. 
  4. If payment is not immediately confirmed by the "Collect Payment [PaymCollectPayment]" process, then confirmation can be received in one of two ways, namely:
    1. Callbacks – the external payment gateway can perform a callback to the "Callback Payment [PaymCallbackPayment]" process indicating the status of the payment. The process will invoke "Process Payment [PaymProcessPayment]" to post the payment against Aria, and it will also update the status of the payment request in AMPS Payment Request
    2. Batch – the external payment gateway may send a file holding details on the payment confirmations. The external payment gateway will call "Process Payment [PaymProcessPayment]" directly to post the payment and update the status of AMPS Payment Request


The refund process is triggered when an approved refund is processed by the "Handle Approved Refunds [PaymHandleApprRefunds]" in the relevant AMPS table is found. Refunds via the external payment gateway is performed only if the Payment Option configuration indicates the external gateway are used. 

  1. When processing an approved refund, the "Handle Approved Refunds [PaymHandleApprRefunds]" will format an "Issue Refund" message and send it to the "Issue Refund [PaymIssueRefund]" process for further processing.
  2. The "Issue Refund [PaymIssueRefund]" process will in turn format the appropriate message and send it to the external payment gateway and await a response. Based on the response received from the external payment gateway, the status of the refund request is updated in the AMPS Payment Request table. If the response indicates that refund is immediately confirmed and "Process Refund [Paym¬Process-Refund]" will post and update the refund request. 
  3. If refund is not immediately confirmed by the "Issue Refund [PaymIssueRefund]" process, then confirmation can be received in one of two ways, namely:
    1. Callbacks – the external payment gateway can perform a callback to the "Callback Payment [PaymCallbackPayment]" process indicating the status of the refund. The process will invoke "Process Refund [PaymProcessRefund]" to post the refund against Aria, and it will also update the status of the payment request in AMPS Payment Request
    2. Batch – the external payment gateway may send a file holding details on the payment confirmations. The external payment gateway will call "Process Payment [PaymProcessPayment]" directly to post the payment and update the status of AMPS Payment Request

Collection via Partner

To be finalized.

Collection via Credit Card

To be finalized.

Note: See "Interface and Integration Definitions for Payment Management" for the API methods used for Payment Management when integrating with AMPS.


Last modified

Tags

This page has no custom tags.

Classifications

This page has no classifications.