Recurring Card Payments (Postpaid)
In recurring card payments, a customer
In the context of the Cloud Monetisation Platform, an individual or organisation who has signed an agreement to take goods and services from a service provider. A customer receives a bill associated with one or more subscriptions, and can be a single end user or a large company with many subscriptions assigned to one agreement. authorises an organisation to take fixed or varied amounts from their credit or debit card, as long as the customer is given advance notice of the collection amounts and dates.
CMP Converged Monetisation Platform. The MDS Global product that supports customer care and billing for digital service providers. supports recurring card payments for both prepaid and postpaid subscriptions. This section deals with postpaid subscriptions.
Recurring card payments in CMP involve the following:
- Setting up the recurring card payment
- Processing the payments
- Handling rejected payments and payment errors
The following diagram illustrates how different CMP components are involved in recurring card payments. In this example, a customer uses a selfcare app to set up a recurring card payment:
Recurring Card Payment Setup
Recurring card payments can be set up as follows:
-
Via selfcare applications and third party
Of software; a reusable component developed to be either freely distributed or sold by an entity other than the original vendor of the development platform. systems using a SOAP web service XML- or JSON-based information exchange systems that use the Internet for direct application-to-application interaction. These systems can include programs, objects, messages, or documents. where Payment Type is a parameter.
Processing Recurring Card Payments (Postpaid)
The CMP Generic Card Payment interface provides a standard, generic output and input format for the handling of recurring credit and debit card payments. The interface assumes the card details have been stored in a secure manner in the payment provider system.
The generic recurring card payment functionality extracts payments and refunds from CMP when they are due and includes them in a generic JSON JavaScript Object Notation. JSON is a lightweight format for storing and transporting data, often used when data is sent from a server to a web page. file by running the Recurring Payments job in CARD mode. The JSON formatted files can be converted by a third party adapter to the required format expected by the payment provider.
Third party adapters can be created by MDS Global, Service Providers, systems integrators etc.
This job creates a batch of payments due for accounts that have been configured to pay by recurring credit or debit card payments. Also included in the batch are accounts that have approved refunds by credit or debit card due.
This job also creates a second batch to post the extracted payments and refunds to the sales ledger. Following the transmission of the extract file, dedicated daemons that format this batch and transmit it to the sales ledger to update the customer Account In the Cloud Monetisation Platform, a billing entity that can be used to manage payments on one or more subscriptions or payments for services. An account can hold details such as payments or invoices. Balance; CMP assuming that no errors will occur in the processing of the payment.
For more information, see the Recurring Payments sections of the CMP Batch Jobs and JSON Schemas Guide.
Handling Recurring Card Payment Rejections
The CMP Generic Card Payment interface also handles recurring card payment rejections. Recurring card payments can fail for a number of reasons such as a lost or stolen card. Recurring card payment rejections are managed in CMP by the Recurring Payments Rejections job.
When CMP receives files containing rejected transactions, these are automatically detected by a dedicated daemon A computer program that runs as a background process, rather than being under the control of an interactive user., which creates a rejected payments batch in CMP for each file received.
Each returned payment includes a reason code. Reason codes are configured in the Payments module of Business Configuration A module in the CMP Administation console that provides for viewing and modification of business and user applicable system configuration.. These reason codes can be configured to determine whether the decline is a:
Soft decline
Soft declines are a result of a temporary error. Payments with soft declines can be retried a specific number of times by including the failed payment on a future recurring payment extract. The number of retries for a specific reason code is configurable in Business Configuration. Each reason code and number of retries for soft declines has an associated workflow event and the appropriate actions to be automatically completed depending on the failure reason. Once the maximum number of retries is reached the recurring card payment is cancelled and treated as a hard decline
Hard Decline
Hard declines are permanent errors and are not retried.
For more information, see the Payments section of the CMP Business Configuration Overview or the online help in the Business Configuration console.
This job generates a batch that contains records to reverse each failed transaction from the sales ledger. Once this batch has been created, it is detected by dedicated daemons, which format the batch and transmit it to the target sales ledger. This job also generates workflows, for example, to send a communication to the customer, processes soft declines to temporarily exclude the account from the automated payments process and processes hard declines to revert the account to the default (manual) payment to make alternative arrangements for collection of amounts due.
For more information, see the Recurring Payments Rejections section of the CMP Batch Jobs and JSON Schemas Guide.