openapi: 3.0.3
info:
description: |-
Service Enabling Payments against Operator Carrier Billing Systems
# Introduction
The Carrier Billing API provides programmable interface for developers and other users (capabilities consumers) to charge an amount on a mobile line.
It can be easily integrated and allows end-users to buy digital content in an easy & secured way. The API provides management of a payment entity and its associated lifecycle.
# Relevant terms and definitions
- **Carrier Billing**:
An online payment process which allows users to make purchases by charging payments against Telco Operator Billing Systems, accordingly to the user's configuration in the Telco Operator. In a common usage in the industry, the payment is processed on current account balance or charged on next bill generated for this line.
- **Payment**:
The process of paying for a (set of) good(s)/service(s).
- **1-STEP Payment**:
Payment process performed in one phase (i.e. one action), that involves all the Telco Operator Carrier Billing Systems checking and trigger the charging request against Billing Systems.
- **2-STEP Payment**:
Payment process performed in two phases (i.e. two actions). First action deals with payment preparation request to guarantee the reservation of the involved amount. Second action is an explicit confirmation or cancellation of the payment by the user. Any payment not confirmed/cancelled by a given user is discarded after some time in order to avoid inconsistency in the billing systems.
# API Functionality
This API allows to third party clients to request the payment of a (set of) digital good(s)/service(s), as well as to retrieve information about a specific payment or a list of payments.
In the scope of **version v0.3, only one-off payments are covered**. Recurrent payments (a.k.a. payment subscriptions) are not covered so far.
The API provides several endpoints/operations:
- An endpoint to request a 1-STEP Payment, named `createPayment`.
- A set of endpoints to request a 2-STEP Payment:
- One endpoint to setup the payment reservation, named `preparePayment`.
- A couple of endpoints to confirm/cancel such payment reservation, named `confirmPayment` and `cancelPayment` respectively.
- A set of endpoints to retrieve information about a list of payments or a specific payment (identified by its specific `paymentId`), named `retrievePayments` and `retrievePayment` respectively.
- A callback endpoint where API Server can send notifications about a payment procedure, as defined within `createPayment` and `preparePayment` operations, towards the `sink` when provided by API client.
The usage of the API is based on Payment resource, which can be created (in 1-STEP or 2-STEP Payment process), confirmed/cancelled (for 2-STEP Payment process), and queried/retrieved (list of payments or a specific payment).
Before starting to use the API, the developer needs to know about the below specified details:
- **Payment service endpoint**: The URL pointing to the RESTful resource of the payment API. As 1-STEP and 2-STEP processes are managed, 2 separate tags _`One Step Payment`_ and _`Two Step Payment`_ have been defined to explicitly distinguish them in the API specification. A third tag _`Payment`_ is defined for common operations in both processes (query/retrieve list of payments or a specific payment).
- **1-STEP & 2-STEP Payment**:
- **1-STEP Payment**: The request intent is to charge an amount to the mobile line. When the server receives the request, it will check the user account associated with this line and, if nothing prevents it, the amount is charged and will be either bill in next invoice or removed from current line credit/balance.
- **2-STEP Payment**: The first call is to request a payment preparation, which implies an amount reservation. The amount is not charged and the server has to be ready to get a confirmation or a cancellation to perform the payment. Only when the confirmation is done, payment is charged. Depending on business rules of the Telco operator, a `prepared` payment could expire after a defined delay.
- **Notification URL**: Developers may provide a callback URL (`sink` param) on which status change notifications, regarding the payment, can be received from the Telco Operator. This is an optional parameter.
Following diagram shows the API resources operation sequencing:
Follow picture provides information about the payment state engine (state description & transition):
State transitions:
**1-STEP Payment**
If `createPayment` is a **SYNC** process:
- Response contains `paymentId` and paymentStatus=`succeeded`.
- In case of any error scenario `paymentId` is not created.
If `createPayment` is an **ASYNC** process:
- Response contains `paymentId` and paymentStatus=`processing`. After completion:
- When payment is successfully completed then paymentStatus=`succeeded`.
- When payment is not successfully performed then paymentStatus=`denied`.
- In case of any error scenario `paymentId` is not created.
**2-STEP Payment**
FIRST STEP
If `preparePayment` is a **SYNC** process:
- **Case A** - `validationInfo` is NOT provided in response.
- Response contains `paymentId` and paymentStatus=`reserved`.
- **Case B** - `validationInfo` is provided in response.
- Response contains `paymentId` and paymentStatus=`pending_validation`.
- In case of any error scenario `paymentId` is not created.
If `preparePayment` is an **ASYNC** process:
- **Case A** - `validationInfo` is NOT provided in response.
- Response contains `paymentId` and paymentStatus=`processing`. After completion:
- When payment preparation is successfully completed then paymentStatus=`reserved`.
- When payment preparation is not successfully performed then paymentStatus=`denied`.
- **Case B** - `validationInfo` is provided in response.
- Response contains `paymentId` and paymentStatus=`processing`. After completion:
- When payment preparation is successfully completed then paymentStatus=`pending_validation`. [1]
- When payment preparation is not successfully performed then paymentStatus=`denied`.
- In case of any error scenario `paymentId` is not created.
[OPTIONAL] VALIDATE STEP [1]
After `validatePayment`, paymentStatus=`reserved` OR `denied`, depending whether it was successful or not.
SECOND STEP
After `confirmPayment`, paymentStatus=`succeeded` OR `denied`, depending whether it was successful or not.
After `cancelPayment`, paymentStatus=`cancelled`.
# Generic Clarification about optional parameters
Regarding optional parameters, they can be conditionally mandatory for a Telco Operator to implement them based on business scenarios or applicable regulations in a given market.
NOTE: Within a given market, in a multi Telco Operator ecosystem, the set of optional parameters to be implemented MUST be aligned among involved Telco Operators.
# Authorization and authentication
The "Camara Security and Interoperability Profile" provides details on how a client requests an access token. Please refer to Identify and Consent Management (https://github.com/camaraproject/IdentityAndConsentManagement/) for the released version of the Profile.
Which specific authorization flows are to be used will be determined during onboarding process, happening between the API Client and the Telco Operator exposing the API, taking into account the declared purpose for accessing the API, while also being subject to the prevailing legal framework dictated by local legislation.
It is important to remark that in cases where personal user data is processed by the API, and users can exercise their rights through mechanisms such as opt-in and/or opt-out, the use of 3-legged access tokens becomes mandatory. This measure ensures that the API remains in strict compliance with user privacy preferences and regulatory obligations, upholding the principles of transparency and user-centric data control.
# Further info and support
(FAQs will be added in a later version of the documentation)
version: 0.3.1
title: Global System for Mobile Communications GSMA Camara Project Carrier Billing
license:
name: Apache 2.0
url: https://www.apache.org/licenses/LICENSE-2.0.html
externalDocs:
description: Product documentation at Camara
url: https://github.com/camaraproject/CarrierBillingCheckOut
x-camara-commonalities: 0.4.0
servers:
- url: "{apiRoot}/carrier-billing/v0.3"
variables:
apiRoot:
default: http://localhost:9091
description: API root, defined by the service provider
tags:
- name: One Step Payment
description: Operations to manage One Step Payment procedure
- name: Payment
description: Operations to obtain information about payments
- name: Two Step Payment
description: Operations to manage Two Step Payment procedure
paths:
/payments:
post:
security:
- openId:
- carrier-billing:payments:create
tags:
- One Step Payment
summary: Global System for Mobile Communications Create a new Payment
operationId: createPayment
description: Create a new payment for subsequent charging to an end user. Carrier Billing Server will apply the charging according to business configuration for the end user.
parameters:
- $ref: "#/components/parameters/x-correlator"
requestBody:
description: Amount transaction
content:
application/json:
schema:
$ref: "#/components/schemas/CreatePayment"
required: true
callbacks:
notifications:
"{$request.body#/sink}":
post:
security:
- {}
- notificationsBearerAuth: []
tags:
- Payment Notifications
summary: Carrier Billing payment notifications
operationId: createPaymentNotification
description: |
Important: This endpoint is exposed by the API client, accepting requests in the defined format.
The Carrier Billing server will call this endpoint whenever any carrier billing related event occurs.
parameters:
- $ref: "#/components/parameters/x-correlator"
requestBody:
description: Creates a new carrier billing payment notification
content:
application/cloudevents+json:
schema:
$ref: "#/components/schemas/CloudEvent"
required: true
responses:
"204":
description: Successful notification
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
"400":
$ref: "#/components/responses/Generic400"
"401":
$ref: "#/components/responses/Generic401"
"403":
$ref: "#/components/responses/Generic403"
"410":
$ref: "#/components/responses/Generic410"
"429":
$ref: "#/components/responses/Generic429"
"500":
$ref: "#/components/responses/Generic500"
"503":
$ref: "#/components/responses/Generic503"
responses:
"201":
description: Created
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
content:
application/json:
schema:
$ref: "#/components/schemas/PaymentCreated"
"400":
$ref: "#/components/responses/PaymentInvalid400"
"401":
$ref: "#/components/responses/Generic401"
"403":
$ref: "#/components/responses/PaymentPermissionDenied403"
"409":
$ref: "#/components/responses/Generic409"
"422":
$ref: "#/components/responses/PaymentUnprocessable422"
"500":
$ref: "#/components/responses/Generic500"
"503":
$ref: "#/components/responses/Generic503"
"504":
$ref: "#/components/responses/Generic504"
get:
security:
- openId:
- carrier-billing:payments:read
tags:
- Payment
summary: Global System for Mobile Communications Get a list of payments
operationId: retrievePayments
description: |-
Retrieve a list of payments and their details based on some filtering criteria.
Regardless the payment criteria provided, response MUST be always limited to payments performed by the API client (i.e same oAuth credentials) triggering this request.
This is to guarantee no API client can check payments performed by other, therefore avoiding any legal or privacy topic.
When Access Token is issued for a given user phone number, the list of payments returned would be only the ones associated to that user phone number and API client. When Access Token is not associated to a user phone number, therefore only associated to API client the list of payments returned would be all the ones managed by that API client.
Considerations regarding `paymentCreationDate.gte`, `paymentCreationDate.lte`:
- If both included, return payments in that date range
- If no one included, no filtering by date range is applied
- If only settled `paymentCreationDate.gte`, `paymentCreationDate.lte` is considered current date-time
- If only settled `paymentCreationDate.lte`, every payment existing in the Operator billing system until such date is returned
parameters:
- $ref: "#/components/parameters/x-correlator"
- $ref: "#/components/parameters/Page"
- $ref: "#/components/parameters/PerPage"
- $ref: "#/components/parameters/StartPaymentCreationDate"
- $ref: "#/components/parameters/EndPaymentCreationDate"
- $ref: "#/components/parameters/Order"
- $ref: "#/components/parameters/PaymentStatus"
- $ref: "#/components/parameters/MerchantIdentifier"
responses:
"200":
description: OK
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
Content-Last-Key:
$ref: "#/components/headers/Content-Last-Key"
X-Total-Count:
$ref: "#/components/headers/X-Total-Count"
content:
application/json:
schema:
$ref: "#/components/schemas/PaymentArray"
"400":
$ref: "#/components/responses/GetPaymentsInvalid400"
"401":
$ref: "#/components/responses/Generic401"
"403":
$ref: "#/components/responses/PaymentReadPermissionDenied403"
"500":
$ref: "#/components/responses/Generic500"
"503":
$ref: "#/components/responses/Generic503"
"504":
$ref: "#/components/responses/Generic504"
/payments/{paymentId}:
get:
security:
- openId:
- carrier-billing:payments:read
tags:
- Payment
summary: Global System for Mobile Communications Get payment details
operationId: retrievePayment
description: |-
Retrieve payment details for a given payment.
When Access Token is issued for a given user phone number, the payment details would be returned in case the `paymentId` is associated to that user phone number and API client, otherwise `404 NOT_FOUND` will be returned. When Access Token is not associated to a user phone number, the payment details are returned in case the API client managed that payment.
parameters:
- name: paymentId
in: path
description: Payment identifier that was obtained from the create payment operation
required: true
schema:
type: string
- $ref: "#/components/parameters/x-correlator"
responses:
"200":
description: OK
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
content:
application/json:
schema:
$ref: "#/components/schemas/Payment"
"401":
$ref: "#/components/responses/Generic401"
"403":
$ref: "#/components/responses/PaymentReadPermissionDenied403"
"404":
$ref: "#/components/responses/Generic404"
"500":
$ref: "#/components/responses/Generic500"
"503":
$ref: "#/components/responses/Generic503"
"504":
$ref: "#/components/responses/Generic504"
/payments/prepare:
post:
security:
- openId:
- carrier-billing:payments:create
tags:
- Two Step Payment
summary: Global System for Mobile Communications Prepare (reserve) a payment
operationId: preparePayment
description: Prepare a new payment procedure. Carrier Billing Server will apply the charging according to business configuration for the end user.
parameters:
- $ref: "#/components/parameters/x-correlator"
requestBody:
description: Amount transaction
content:
application/json:
schema:
$ref: "#/components/schemas/BodyAmountReservationTransactionForReserveInput"
required: true
callbacks:
notifications:
"{$request.body#/sink}":
post:
security:
- {}
- notificationsBearerAuth: []
tags:
- Payment Notifications
summary: Carrier Billing payment notifications
operationId: preparePaymentNotification
description: |
Important: This endpoint is exposed by the API client, accepting requests in the defined format.
The Carrier Billing server will call this endpoint whenever any carrier billing related event occurs.
parameters:
- $ref: "#/components/parameters/x-correlator"
requestBody:
description: Creates a new carrier billing payment notification
content:
application/cloudevents+json:
schema:
$ref: "#/components/schemas/CloudEvent"
required: true
responses:
"204":
description: Successful notification
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
"400":
$ref: "#/components/responses/Generic400"
"401":
$ref: "#/components/responses/Generic401"
"403":
$ref: "#/components/responses/Generic403"
"410":
$ref: "#/components/responses/Generic410"
"429":
$ref: "#/components/responses/Generic429"
"500":
$ref: "#/components/responses/Generic500"
"503":
$ref: "#/components/responses/Generic503"
responses:
"201":
description: Created
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
content:
application/json:
schema:
$ref: "#/components/schemas/BodyAmountReservationTransactionForReserve"
"400":
$ref: "#/components/responses/Payment2StepPrepareInvalid400"
"401":
$ref: "#/components/responses/Generic401"
"403":
$ref: "#/components/responses/PaymentPermissionDenied403"
"409":
description: Conflict
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
content:
application/json:
schema:
$ref: "#/components/schemas/ErrorInfo"
example:
code: ALREADY_EXISTS
status: 409
message: "Another session is created for the same UE"
"422":
$ref: "#/components/responses/PaymentUnprocessable422"
"500":
$ref: "#/components/responses/Generic500"
"503":
$ref: "#/components/responses/Generic503"
"504":
$ref: "#/components/responses/Generic504"
/payments/{paymentId}/validate:
post:
security:
- openId:
- carrier-billing:payments:write
tags:
- Two Step Payment
summary: Global System for Mobile Communications Validate a payment
operationId: validatePayment
description: Validate a given payment with a code, identified by its paymentId. This process is applicable for 2-STEP, when optionally required by business case.
parameters:
- name: paymentId
in: path
description: The payment identifier returned when the payment preparation was created.
schema:
type: string
required: true
- $ref: "#/components/parameters/x-correlator"
requestBody:
description: Payment Validation
content:
application/json:
schema:
$ref: "#/components/schemas/ValidatePayment"
required: true
responses:
"204":
description: Validation Succeeded
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
"400":
$ref: "#/components/responses/ValidatePaymentInvalid400"
"401":
$ref: "#/components/responses/Generic401"
"403":
$ref: "#/components/responses/Generic403"
"409":
description: Conflict
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
content:
application/json:
schema:
$ref: "#/components/schemas/ErrorInfo"
examples:
Generic409:
summary: Conflict
value:
code: ALREADY_EXISTS
status: 409
message: "Payment already validated"
"500":
$ref: "#/components/responses/Generic500"
"503":
$ref: "#/components/responses/Generic503"
"504":
$ref: "#/components/responses/Generic504"
/payments/{paymentId}/confirm:
post:
security:
- openId:
- carrier-billing:payments:write
tags:
- Two Step Payment
summary: Global System for Mobile Communications Confirm a payment
operationId: confirmPayment
description: Confirm a reservation of a given payment, identified by its paymentId.
parameters:
- name: paymentId
in: path
description: The payment identifier returned when the payment preparation was created.
schema:
type: string
required: true
- $ref: "#/components/parameters/x-correlator"
requestBody:
description: capture PhoneNumber for payment operation
content:
application/json:
schema:
$ref: "#/components/schemas/PhoneNumber"
required: true
responses:
"202":
description: Payment confirmation accepted
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
"400":
$ref: "#/components/responses/Payment2StepInvalid400"
"401":
$ref: "#/components/responses/Generic401"
"403":
$ref: "#/components/responses/PaymentConfirmPermissionDenied403"
"404":
$ref: "#/components/responses/Generic404"
"409":
$ref: "#/components/responses/PaymentConfirmConflict409"
"422":
$ref: "#/components/responses/PaymentSecondStepUnprocessable422"
"500":
$ref: "#/components/responses/Generic500"
"503":
$ref: "#/components/responses/Generic503"
"504":
$ref: "#/components/responses/Generic504"
/payments/{paymentId}/cancel:
post:
security:
- openId:
- carrier-billing:payments:write
tags:
- Two Step Payment
summary: Global System for Mobile Communications Cancel a payment
operationId: cancelPayment
description: Cancel a reservation of a given payment, identified by its paymentId.
parameters:
- name: paymentId
in: path
description: The payment identifier returned when the payment preparation was created.
required: true
schema:
type: string
- $ref: "#/components/parameters/x-correlator"
requestBody:
description: capture PhoneNumber for payment operation
content:
application/json:
schema:
$ref: "#/components/schemas/PhoneNumber"
required: true
responses:
"202":
description: Payment Cancellation Accepted
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
"400":
$ref: "#/components/responses/Payment2StepInvalid400"
"401":
$ref: "#/components/responses/Generic401"
"403":
$ref: "#/components/responses/PaymentCancelPermissionDenied403"
"404":
$ref: "#/components/responses/Generic404"
"409":
$ref: "#/components/responses/PaymentCancelConflict409"
"422":
$ref: "#/components/responses/PaymentSecondStepUnprocessable422"
"500":
$ref: "#/components/responses/Generic500"
"503":
$ref: "#/components/responses/Generic503"
"504":
$ref: "#/components/responses/Generic504"
components:
securitySchemes:
openId:
type: openIdConnect
openIdConnectUrl: https://example.com/.well-known/openid-configuration
notificationsBearerAuth:
type: http
scheme: bearer
bearerFormat: "{$request.body#/sinkCredential.credentialType}"
schemas:
CreatePayment:
type: object
required:
- amountTransaction
properties:
amountTransaction:
$ref: "#/components/schemas/AmountTransactionInput"
sink:
type: string
format: url
description: The address to which events shall be delivered, using the HTTP protocol.
example: "https://endpoint.example.com/sink"
sinkCredential:
allOf:
- description: A sink credential provides authentication or authorization information necessary to enable delivery of events to a target.
- $ref: "#/components/schemas/SinkCredential"
PaymentCreated:
type: object
required:
- amountTransaction
- paymentId
- paymentStatus
- paymentCreationDate
properties:
paymentId:
type: string
description: Unique Identifier of the payment
example: "AK234rfweSBuWGFUEWFGWEVWRV"
amountTransaction:
$ref: "#/components/schemas/AmountTransaction"
paymentStatus:
type: string
description: Specifies the payment status (`processing`, `pending_validation`, `denied`, `reserved`, `succeeded`, `cancelled`).
example: "processing"
paymentCreationDate:
type: string
format: date-time
description: Date time when the payment is created in server database. This is a technical information. It must follow RFC 3339 and must have time zone. Recommended format is yyyy-MM-dd'T'HH:mm:ss.SSSZ (i.e. which allows 2023-07-03T14:27:08.312+02:00 or 2023-07-03T12:27:08.312Z).
paymentDate:
type: string
format: date-time
description: Date time when the payment is effectively performed. This is a business information. It must follow RFC 3339 and must have time zone. Recommended format is yyyy-MM-dd'T'HH:mm:ss.SSSZ (i.e. which allows 2023-07-03T14:27:08.312+02:00 or 2023-07-03T12:27:08.312Z).
sink:
type: string
format: url
description: The address to which events shall be delivered, using the HTTP protocol.
example: "https://endpoint.example.com/sink"
sinkCredential:
allOf:
- description: A sink credential provides authentication or authorization information necessary to enable delivery of events to a target.
- $ref: "#/components/schemas/SinkCredential"
PaymentArray:
description: A list of payment(s)
type: array
minItems: 0
items:
$ref: "#/components/schemas/Payment"
Payment:
type: object
required:
- amountTransaction
- paymentId
- paymentStatus
- paymentCreationDate
properties:
paymentId:
type: string
description: Unique Identifier of the payment
example: "AK234rfweSBuWGFUEWFGWEVWRV"
amountTransaction:
$ref: "#/components/schemas/AmountTransaction"
paymentStatus:
type: string
description: Specifies the payment status (`processing`, `pending_validation`, `denied`, `reserved`, `succeeded`, `cancelled`).
example: "processing"
paymentCreationDate:
type: string
format: date-time
description: Date time when the payment is created in server database. This is a technical information. It must follow RFC 3339 and must have time zone. Recommended format is yyyy-MM-dd'T'HH:mm:ss.SSSZ (i.e. which allows 2023-07-03T14:27:08.312+02:00 or 2023-07-03T12:27:08.312Z).
paymentDate:
type: string
format: date-time
description: Date time when the payment is effectively performed. This is a business information. It must follow RFC 3339 and must have time zone. Recommended format is yyyy-MM-dd'T'HH:mm:ss.SSSZ (i.e. which allows 2023-07-03T14:27:08.312+02:00 or 2023-07-03T12:27:08.312Z).
sink:
type: string
format: url
description: The address to which events shall be delivered, using the HTTP protocol.
example: "https://endpoint.example.com/sink"
sinkCredential:
allOf:
- description: A sink credential provides authentication or authorization information necessary to enable delivery of events to a target.
- $ref: "#/components/schemas/SinkCredential"
SinkCredential:
type: object
properties:
credentialType:
type: string
enum:
- PLAIN
- ACCESSTOKEN
- REFRESHTOKEN
description: "The type of the credential. Only `ACCESSTOKEN` is supported so far."
discriminator:
propertyName: credentialType
mapping:
PLAIN: "#/components/schemas/PlainCredential"
ACCESSTOKEN: "#/components/schemas/AccessTokenCredential"
REFRESHTOKEN: "#/components/schemas/RefreshTokenCredential"
required:
- credentialType
PlainCredential:
type: object
description: A plain credential as a combination of an identifier and a secret.
allOf:
- $ref: "#/components/schemas/SinkCredential"
- type: object
required:
- identifier
- secret
properties:
identifier:
description: The identifier might be an account or username.
type: string
secret:
description: The secret might be a password or passphrase.
type: string
AccessTokenCredential:
type: object
description: An access token credential.
allOf:
- $ref: "#/components/schemas/SinkCredential"
- type: object
properties:
# --- truncated at 32 KB (90 KB total) ---
# Full source: https://raw.githubusercontent.com/api-evangelist/global-system-for-mobile-communications/refs/heads/main/openapi/carrier-billing-api-openapi.yml