CAMARA Carrier Billing Checkout API

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.5rc1, 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:
    ![PaymentSequence](https://raw.githubusercontent.com/camaraproject/CarrierBillingCheckOut/r3.2/documentation/API_documentation/resources/Carrier_Billing_sequence_diagram.png)

    Follow picture provides information about the payment state engine (state description & transition):
    ![Payment State Engine](https://raw.githubusercontent.com/camaraproject/CarrierBillingCheckOut/r3.2/documentation/API_documentation/resources/Carrier_Billing_State_Engine.JPG)

    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 of how an API consumer requests an access token. Please refer to Identity and Consent Management (https://github.com/camaraproject/IdentityAndConsentManagement/) for the released version of the profile.

    The specific authorization flows to be used will be agreed upon during the onboarding process, happening between the API consumer and the API provider, taking into account the declared purpose for accessing the API, whilst also being subject to the prevailing legal framework dictated by local legislation.

    In cases where personal 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 three-legged access tokens is mandatory. This ensures that the API remains in compliance with privacy regulations, upholding the principles of transparency and user-centric privacy-by-design.

    # Identifying the phone number from the access token

    This API requires the API consumer to identify a phone number as the subject of the API as follows:
    - When the API is invoked using a two-legged access token, the subject will be identified from the optional `phoneNumber` field, which therefore MUST be provided.
    - When a three-legged access token is used however, this optional identifier MUST NOT be provided, as the subject will be uniquely identified from the access token.

    This approach simplifies API usage for API consumers using a three-legged access token to invoke the API by relying on the information that is associated with the access token and was identified during the authentication process.

    ## Error handling:

    - If the subject cannot be identified from the access token and the optional `phoneNumber` field is not included in the request, then the server will return an error with the `422 MISSING_IDENTIFIER` error code.

    - If the subject can be identified from the access token and the optional `phoneNumber` field is also included in the request, then the server will return an error with the `422 UNNECESSARY_IDENTIFIER` error code. This will be the case even if the same phone number is identified by these two methods, as the server is unable to make this comparison.

    # Additional CAMARA error responses

    The list of error codes in this API specification is not exhaustive. Therefore the API specification may not document some non-mandatory error statuses as indicated in `CAMARA API Design Guide`.

    Please refer to the `CAMARA_common.yaml` of the Commonalities Release associated to this API version for a complete list of error responses. The applicable Commonalities Release can be identified in the `API Readiness Checklist` document associated to this API version.

    As a specific rule, error `501 - NOT_IMPLEMENTED` can be only a possible error response if it is explicitly documented in the API.

    # Further info and support

    (FAQs will be added in a later version of the documentation)
  version: wip
  title: Carrier Billing
  license:
    name: Apache 2.0
    url: https://www.apache.org/licenses/LICENSE-2.0.html
  x-camara-commonalities: wip
externalDocs:
  description: Product documentation at Camara
  url: https://github.com/camaraproject/CarrierBillingCheckOut
servers:
  - url: "{apiRoot}/carrier-billing/vwip"
    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: Two Step Payment
    description: Operations to manage Two Step Payment procedure
  - name: Payment
    description: Operations to obtain information about payments
paths:
  /payments:
    post:
      security:
        - openId:
            - carrier-billing:payments:create
      tags:
        - One Step Payment
      summary: 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"
      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"
        "404":
          $ref: "#/components/responses/IdentifierNotFound404"
        "409":
          $ref: "#/components/responses/Generic409"
        "422":
          $ref: "#/components/responses/PaymentUnprocessable422"
        "429":
          $ref: "#/components/responses/Generic429"
    get:
      security:
        - openId:
            - carrier-billing:payments:read
      tags:
        - Payment
      summary: 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/Generic403"
        "429":
          $ref: "#/components/responses/Generic429"
  /payments/{paymentId}:
    get:
      security:
        - openId:
            - carrier-billing:payments:read
      tags:
        - Payment
      summary: 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"
        "400":
          $ref: "#/components/responses/Generic400"
        "401":
          $ref: "#/components/responses/Generic401"
        "403":
          $ref: "#/components/responses/Generic403"
        "404":
          $ref: "#/components/responses/Generic404"
        "429":
          $ref: "#/components/responses/Generic429"
  /payments/prepare:
    post:
      security:
        - openId:
            - carrier-billing:payments:create
      tags:
        - Two Step Payment
      summary: 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"
      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"
        "404":
          $ref: "#/components/responses/IdentifierNotFound404"
        "409":
          description: Conflict
          headers:
            x-correlator:
              $ref: "#/components/headers/x-correlator"
          content:
            application/json:
              schema:
                allOf:
                  - $ref: "#/components/schemas/ErrorInfo"
                  - type: object
                    properties:
                      status:
                        enum:
                          - 409
                      code:
                        enum:
                          - ALREADY_EXISTS
              examples:
                GENERIC_409_ALREADY_EXISTS:
                  summary: Generic Already Exists
                  description: Trying to create an existing resource
                  value:
                    code: ALREADY_EXISTS
                    status: 409
                    message: "Another session is created for the same UE"
        "422":
          $ref: "#/components/responses/PaymentUnprocessable422"
        "429":
          $ref: "#/components/responses/Generic429"
  /payments/{paymentId}/validate:
    post:
      security:
        - openId:
            - carrier-billing:payments:write
      tags:
        - Two Step Payment
      summary: 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"
        "404":
          $ref: "#/components/responses/Generic404"
        "409":
          description: Conflict
          headers:
            x-correlator:
              $ref: "#/components/headers/x-correlator"
          content:
            application/json:
              schema:
                allOf:
                  - $ref: "#/components/schemas/ErrorInfo"
                  - type: object
                    properties:
                      status:
                        enum:
                          - 409
                      code:
                        enum:
                          - ALREADY_EXISTS
              examples:
                GENERIC_409_ALREADY_EXISTS:
                  summary: Conflict
                  description: paymentId already validated
                  value:
                    code: ALREADY_EXISTS
                    status: 409
                    message: "Payment already validated"
        "429":
          $ref: "#/components/responses/Generic429"
  /payments/{paymentId}/confirm:
    post:
      security:
        - openId:
            - carrier-billing:payments:write
      tags:
        - Two Step Payment
      summary: 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/Identifier2StepNotFound404"
        "409":
          $ref: "#/components/responses/PaymentConfirmConflict409"
        "422":
          $ref: "#/components/responses/PaymentSecondStepUnprocessable422"
        "429":
          $ref: "#/components/responses/Generic429"
  /payments/{paymentId}/cancel:
    post:
      security:
        - openId:
            - carrier-billing:payments:write
      tags:
        - Two Step Payment
      summary: 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/Identifier2StepNotFound404"
        "409":
          $ref: "#/components/responses/PaymentCancelConflict409"
        "422":
          $ref: "#/components/responses/PaymentSecondStepUnprocessable422"
        "429":
          $ref: "#/components/responses/Generic429"
components:
  securitySchemes:
    openId:
      type: openIdConnect
      openIdConnectUrl: https://example.com/.well-known/openid-configuration
    notificationsBearerAuth:
      type: http
      scheme: bearer
      bearerFormat: "{$request.body#/sinkCredential.credentialType}"
  schemas:
    XCorrelator:
      type: string
      pattern: ^[a-zA-Z0-9-_:;.\/<>{}]{0,256}$
      example: "b4333c46-49c0-4f62-80d7-f0ef930f1c46"
    CreatePayment:
      type: object
      required:
        - amountTransaction
      properties:
        amountTransaction:
          $ref: "#/components/schemas/AmountTransactionInput"
        sink:
          type: string
          format: uri
          pattern: ^https:\/\/.+$
          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](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must have time zone.
        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](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must have time zone.
        sink:
          type: string
          format: uri
          pattern: ^https:\/\/.+$
          description: The address to which events shall be delivered, using the HTTP protocol.
          example: "https://endpoint.example.com/sink"
    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](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must have time zone.
        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](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must have time zone.
        sink:
          type: string
          format: uri
          pattern: ^https:\/\/.+$
          description: The address to which events shall be delivered, using the HTTP protocol.
          example: "https://endpoint.example.com/sink"
    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/AccessToke

# --- truncated at 32 KB (97 KB total) ---
# Full source: https://raw.githubusercontent.com/api-evangelist/camara-project/refs/heads/main/openapi/carrier-billing-openapi.yml