|
|
This chapter describes the Parlay X 3.0 Payment communication service in detail:
The SOAP Service Facade Payment communication service implements the Parlay X 3.0 Payment set of interfaces. For the exact version of the standard these communication services support, see “Appendix A: Standards and Specifications” in Concepts and Architectural Overview, another document in this set.
| Note: | The RESTful Service Payment interfaces provide RESTful access to this same functionality. The internal representations are identical, and for the purposes of creating SLAs and reading CDRs, etc., they are the same. |
Using a Payment communication service, an application can:
All charging is done on accounts. The unit of charge is specified as a given currency or a charging code.
If an application makes a request to interact directly with an account, Oracle Communications Oracle Communications Services Gatekeeper sends the request to the network node capable of handling the request. The request does not return until the targeted account has been updated.
There are no notifications are network-triggered requests for this communications service.
Off the shelf, the Payment communication service can be configured to support the following network protocols:
The Payment communication service acts as an on-line charging application using the Diameter Ro interface. See “Appendix A: Standards and Specifications” in Concepts and Architectural Overview for the exact version of the standard Oracle Communications Services Gatekeeper supports.
Oracle Communications Services Gatekeeper connects to the Diameter server, and acts as a single on-line charging application.
A reservation expires after a given time. The expiry mechanism provided by the Storage Service is used. If the store entry expires, the reservation is cancelled.
Some Diameter servers, for example Oracle Billing and Revenue Management, mandates that a refund operation is correlated with previous charge operation. The Parlay X 2.1 Payment interface does not provide any correlation between charge operations and refund operations. The tunnelled parameter session-id has been added in order to correlated these requests. When an application calls chargeAmount, the tunnelled parameter session-id is returned in the SOAP header. An application should use this session-id in subsequent requests to refundAmount to correlate the two requests. If the application does not provided the tunneled parameter, it is the responsibility of the Diameter server to either accept to deny the request. If the request is denied, the application receives a ServiceException.
Communication services share many common features, covered in “Introducing Communication Services” in Concepts and Architectural Overview, but each one has a few characteristics that are specific only to that service. This section describes those specific features for the Payment communication services, including:
In the Payment/Diameter communication service, CDRs are written when the response to a request is successfully delivered to the application. All methods trigger the generation of CDRs:
Events for Payment/Diameter are documented in Table 10-1. For more information, see Events, Alarms, and Charging..
Table 10-2 outlines the correlation between the methods being invoked from the application and the transaction type collected by the statistics counters in Oracle Communications Services Gatekeeper for the Parlay X 3.0 Payment/Diameter communication service:
The Parlay X 3.0 Payment/Diameter communication service supports the tel: address scheme.
|