# Communication Service Reference

# Parlay X 3.0 Payment Communication Services

This chapter describes the Parlay X 3.0 Payment communication service in detail:

- An Overview of the Parlay X 3.0 Payment Communication Service

- Processing Direct Queries/Application-initiated Requests
- Processing Notifications/Network-triggered Requests
- Supported Network Protocols

- Configuration Specifics for the Parlay X 3. 0 Payment Communication Services

- Charging Data Records
- Event Data Records
- Statistics
- Supported Address Schemes

## An Overview of the Parlay X 3.0 Payment Communication Service

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:

- Charge and refund accounts directly
- Operate on reservations:

- Make reservations
- Charge reservation
- Release reservations

- Charge multiple accounts concurrently

All charging is done on accounts. The unit of charge is specified as a given currency or a charging code.

### Processing Direct Queries/Application-initiated Requests

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.

### Processing Notifications/Network-triggered Requests

There are no notifications are network-triggered requests for this communications service.

### Supported Network Protocols

Off the shelf, the Payment communication service can be configured to support the following network protocols:

- Diameter

#### Diameter

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.

## Configuration Specifics for the Parlay X 3. 0 Payment Communication Services

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:

- Charging Data Records
- Event Data Records
- Statistics
- Supported Address Schemes

### Charging Data Records

#### Generation of CDRs

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:

- `chargeAmount`
- `refundAmount`
- `chargeSplitAmount`
- `reserveAmount`
- `reserveAdditionalAmount`
- `chargeReservation`
- `releaseReservation`

### Event Data Records

Events for Payment/Diameter are documented in Table 10-1. For more information, see Events, Alarms, and Charging..

Table 10-1 Event types emitted in Payment/Diameter communication service
EdrId | Description
--- | ---
15001 | chargeAmount
15002 | refundAmount
15003 | chargeSplitAmount
15004 | reserveAmount
15005 | reserveAdditionalAmount
15006 | chargeReservation
15007 | releaseReservation

### Statistics

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:

Table 10-2 Transaction types for Parlay X 3.0 Payment/Diameter communication service
Method | Transaction type
--- | ---
chargeAmount | TRANSACTION_TYPE_CHARGING_DIRECT
chargeSplitAmount | TRANSACTION_TYPE_CHARGING_DIRECT
refundAmount | TRANSACTION_TYPE_CHARGING_DIRECT
reserveAmount | TRANSACTION_TYPE_CHARGING_RESERVED_STRING
reserveAdditionalAmount | TRANSACTION_TYPE_CHARGING_RESERVED_STRING
chargeReservation | TRANSACTION_TYPE_CHARGING_RESERVED_STRING

### Supported Address Schemes

The Parlay X 3.0 Payment/Diameter communication service supports the `tel:` address scheme.