GSMA Open Gateway Two Step Payment API

openapi: 3.2.0
info:
  description: "Service Enabling Payments against Operator Carrier Billing Systems\n\n# Introduction\n\nThe Carrier Billing API provides programmable interface for developers and other users (capabilities consumers) to charge an amount on a mobile line.\nIt 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.\n\n# Relevant terms and definitions\n\n- **Carrier Billing**:\nAn 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.\n\n- **Payment**:\nThe process of paying for a (set of) good(s)/service(s).\n\n- **1-STEP Payment**:\nPayment 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.\n\n- **2-STEP Payment**:\nPayment 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.\n\n# API Functionality\n\nThis 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.\n\nIn the scope of **version v0.5rc1, only one-off payments are covered**. Recurrent payments (a.k.a. payment subscriptions) are not covered so far.\n\nThe API provides several endpoints/operations:\n- An endpoint to request a 1-STEP Payment, named `createPayment`.\n- A set of endpoints to request a 2-STEP Payment:\n  - One endpoint to setup the payment reservation, named `preparePayment`.\n  - A couple of endpoints to confirm/cancel such payment reservation, named `confirmPayment` and `cancelPayment` respectively.\n- 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.\n- 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.\n\nThe 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).\n\nBefore starting to use the API, the developer needs to know about the below specified details:\n- **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).\n- **1-STEP & 2-STEP Payment**:\n  - **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.\n  - **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.\n- **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.\n\nFollowing diagram shows the API resources operation sequencing:\n![PaymentSequence](https://raw.githubusercontent.com/camaraproject/CarrierBillingCheckOut/r3.2/documentation/API_documentation/resources/Carrier_Billing_sequence_diagram.png)\n\nFollow picture provides information about the payment state engine (state description & transition):\n![Payment State Engine](https://raw.githubusercontent.com/camaraproject/CarrierBillingCheckOut/r3.2/documentation/API_documentation/resources/Carrier_Billing_State_Engine.JPG)\n\nState transitions:\n\n**1-STEP Payment**\n\nIf `createPayment` is a **SYNC** process:\n- Response contains `paymentId` and paymentStatus=`succeeded`.\n- In case of any error scenario `paymentId` is not created.\n\nIf `createPayment` is an **ASYNC** process:\n- Response contains `paymentId` and paymentStatus=`processing`. After completion:\n  - When payment is successfully completed then paymentStatus=`succeeded`.\n  - When payment is not successfully performed then paymentStatus=`denied`.\n- In case of any error scenario `paymentId` is not created.\n\n**2-STEP Payment**\n\nFIRST STEP\n\nIf `preparePayment` is a **SYNC** process:\n- **Case A** - `validationInfo` is NOT provided in response.\n  - Response contains `paymentId` and paymentStatus=`reserved`.\n- **Case B** - `validationInfo` is provided in response.\n  - Response contains `paymentId` and paymentStatus=`pending_validation`.\n- In case of any error scenario `paymentId` is not created.\n\nIf `preparePayment` is an **ASYNC** process:\n- **Case A** - `validationInfo` is NOT provided in response.\n  - Response contains `paymentId` and paymentStatus=`processing`. After completion:\n    - When payment preparation is successfully completed then paymentStatus=`reserved`.\n    - When payment preparation is not successfully performed then paymentStatus=`denied`.\n- **Case B** - `validationInfo` is provided in response.\n  - Response contains `paymentId` and paymentStatus=`processing`. After completion:\n    - When payment preparation is successfully completed then paymentStatus=`pending_validation`. [1]\n    - When payment preparation is not successfully performed then paymentStatus=`denied`.\n- In case of any error scenario `paymentId` is not created.\n\n[OPTIONAL] VALIDATE STEP [1]\n\nAfter `validatePayment`, paymentStatus=`reserved` OR `denied`, depending whether it was successful or not.\n\nSECOND STEP\n\nAfter `confirmPayment`, paymentStatus=`succeeded` OR `denied`, depending whether it was successful or not.\n\nAfter `cancelPayment`, paymentStatus=`cancelled`.\n\n# Generic Clarification about optional parameters\n\nRegarding 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.\n\nNOTE: 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.\n\n# Authorization and authentication\n\nThe \"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.\n\nThe 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.\n\nIn 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.\n\n# Identifying the phone number from the access token\n\nThis API requires the API consumer to identify a phone number as the subject of the API as follows:\n- 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.\n- 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.\n\nThis 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.\n\n## Error handling:\n\n- 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.\n\n- 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.\n\n# Additional CAMARA error responses\n\nThe 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`.\n\nPlease 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.\n\nAs a specific rule, error `501 - NOT_IMPLEMENTED` can be only a possible error response if it is explicitly documented in the API.\n\n# Further info and support\n\n(FAQs will be added in a later version of the documentation)"
  version: 0.5.0
  title: Carrier Billing Two Step Payment API
  license:
    name: Apache 2.0
    url: https://www.apache.org/licenses/LICENSE-2.0.html
  x-camara-commonalities: 0.6
servers:
- url: '{apiRoot}/carrier-billing/v0.5'
  variables:
    apiRoot:
      default: http://localhost:9091
      description: API root, defined by the service provider
tags:
- name: Two Step Payment
  description: Operations to manage Two Step Payment procedure
paths:
  /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:
  responses:
    Payment2StepInvalid400:
      description: "Invalid input.\nCommon INVALID_ARGUMENT scenarios usually are:\n  - Schema validation failed (\"code\": \"INVALID_ARGUMENT\",\"message\": \"Client specified an invalid argument, request body or query param.\").\n  - paymentId is required (\"code\": \"INVALID_ARGUMENT\",\"message\": \"Expected property is missing: paymentId.\")."
      headers:
        x-correlator:
          $ref: '#/components/headers/x-correlator'
      content:
        application/json:
          schema:
            allOf:
            - $ref: '#/components/schemas/ErrorInfo'
            - type: object
              properties:
                status:
                  enum:
                  - 400
                code:
                  enum:
                  - INVALID_ARGUMENT
          examples:
            GENERIC_400_INVALID_ARGUMENT:
              summary: Generic Invalid Argument
              description: Invalid Argument. Generic Syntax Exception
              value:
                status: 400
                code: INVALID_ARGUMENT
                message: Client specified an invalid argument, request body or query param.
            GENERIC_400_PAYMENT_ID_REQUIRED:
              summary: Generic PaymentId required
              description: paymentId is required
              value:
                code: INVALID_ARGUMENT
                status: 400
                message: 'Expected property is missing: paymentId.'
    PaymentConfirmConflict409:
      description: "Conflict. In addition of regular ALREADY_EXISTS scenario other scenarios may exist:\n  - paymentId is already confirmed (\"code\": \"CARRIER_BILLING.PAYMENT_CONFIRMED\",\"message\": \"Payment has been confirmed.\").\n  - paymentId is already cancelled (\"code\": \"CARRIER_BILLING.PAYMENT_CANCELLED\",\"message\": \"Payment has been cancelled.\")."
      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
                  - CARRIER_BILLING.PAYMENT_CONFIRMED
                  - CARRIER_BILLING.PAYMENT_CANCELLED
          examples:
            GENERIC_409_ALREADY_EXISTS:
              summary: Generic Already Exists
              description: Trying to create an existing resource
              value:
                status: 409
                code: ALREADY_EXISTS
                message: The resource that a client tried to create already exists.
            GENERIC_409_ALREADY_CONFIRMED:
              summary: Generic Already Confirmed
              description: paymentId is already confirmed
              value:
                code: CARRIER_BILLING.PAYMENT_CONFIRMED
                status: 409
                message: Payment has been confirmed.
            GENERIC_409_ALREADY_CANCELLED:
              summary: Generic Already Cancelled
              description: paymentId is already cancelled
              value:
                code: CARRIER_BILLING.PAYMENT_CANCELLED
                status: 409
                message: Payment has been cancelled.
    PaymentCancelPermissionDenied403:
      description: Client does not have sufficient permission.
      headers:
        x-correlator:
          $ref: '#/components/headers/x-correlator'
      content:
        application/json:
          schema:
            allOf:
            - $ref: '#/components/schemas/ErrorInfo'
            - type: object
              properties:
                status:
                  enum:
                  - 403
                code:
                  enum:
                  - PERMISSION_DENIED
          examples:
            GENERIC_403_PERMISSION_DENIED:
              description: Permission denied. OAuth2 token access does not have the required scope or when the user fails operational security
              value:
                status: 403
                code: PERMISSION_DENIED
                message: Client does not have sufficient permissions to perform this action.
    Generic401:
      description: Unauthorized
      headers:
        x-correlator:
          $ref: '#/components/headers/x-correlator'
      content:
        application/json:
          schema:
            allOf:
            - $ref: '#/components/schemas/ErrorInfo'
            - type: object
              properties:
                status:
                  enum:
                  - 401
                code:
                  enum:
                  - UNAUTHENTICATED
          examples:
            GENERIC_401_UNAUTHENTICATED:
              description: Request cannot be authenticated and a new authentication is required
              value:
                status: 401
                code: UNAUTHENTICATED
                message: Request not authenticated due to missing, invalid, or expired credentials. A new authentication is required.
    ValidatePaymentInvalid400:
      description: "Invalid input.\nIn addition to regular INVALID_ARGUMENT scenario other scenarios may exist:\n  - authorizationId is not valid (\"code\": \"CARRIER_BILLING.INVALID_AUTHORIZATION_ID\",\"message\": \"Invalid authorizationId.\").\n  - code is not valid (\"code\": \"CARRIER_BILLING.INVALID_CODE\",\"message\": \"Invalid code.\").\n  - validation failed (\"code\": \"CARRIER_BILLING.VALIDATION_FAILED\",\"message\": \"the maximum number of attempts have been consumed for this validation.\")."
      headers:
        x-correlator:
          $ref: '#/components/headers/x-correlator'
      content:
        application/json:
          schema:
            allOf:
            - $ref: '#/components/schemas/ErrorInfo'
            - type: object
              properties:
                status:
                  enum:
                  - 400
                code:
                  enum:
                  - INVALID_ARGUMENT
                  - CARRIER_BILLING.INVALID_AUTHORIZATION_ID
                  - CARRIER_BILLING.INVALID_CODE
                  - CARRIER_BILLING.VALIDATION_FAILED
          examples:
            GENERIC_400_INVALID_ARGUMENT:
              summary: Generic Invalid Argument
              description: Invalid Argument. Generic Syntax Exception
              value:
                status: 400
                code: INVALID_ARGUMENT
                message: Client specified an invalid argument, request body or query param.
            GENERIC_400_AUTHORIZATION_ID_REQUIRED:
              summary: Generic AuthorizationId Required
              description: authorizationId is required
              value:
                code: INVALID_ARGUMENT
                status: 400
                message: 'Expected property is missing: authorizationId.'
            GENERIC_400_CODE_REQUIRED:
              summary: Generic Code Required
              description: code is required
              value:
                code: INVALID_ARGUMENT
                status: 400
                message: 'Expected property is missing: code.'
            GENERIC_400_INVALID_AUTHORIZATION_ID:
              summary: Generic Invalid Authorization Id
              description: authorizationId is not valid
              value:
                code: CARRIER_BILLING.INVALID_AUTHORIZATION_ID
                status: 400
                message: Invalid authorizationId.
            GENERIC_400_INVALID_CODE:
              summary: Generic Invalid Code
              description: code is not valid
              value:
                code: CARRIER_BILLING.INVALID_CODE
                status: 400
                message: Invalid code.
            GENERIC_400_VALIDATION_FAILED:
              summary: Generic Validation Failed
              description: validation failed
              value:
                code: CARRIER_BILLING.VALIDATION_FAILED
                status: 400
                message: the maximum number of attempts have been consumed for this validation.
    PaymentSecondStepUnprocessable422:
      description: "Client indicates content that is understable by the Server but unable to be processed.\nScenarios that may exist:\n  - Service not applicable for the provided identifier (\"code\": \"SERVICE_NOT_APPLICABLE\",\"message\": \"The service is not available for the provided identifier.\")\n  - An identifier is not included in the request and the device or phone number identification cannot be derived from the 3-legged access token (\"code\": \"MISSING_IDENTIFIER\",\"message\": \"The phone number cannot be identified.\")\n  - An explicit identifier is provided when a device or phone number has already been identified from the access token (\"code\": \"UNNECESSARY_IDENTIFIER\",\"message\": \"The phone number is already identified by the access token.\")"
      headers:
        x-correlator:
          $ref: '#/components/headers/x-correlator'
      content:
        application/json:
          schema:
            allOf:
            - $ref: '#/components/schemas/ErrorInfo'
            - type: object
              properties:
                status:
                  enum:
                  - 422
                code:
                  enum:
                  - SERVICE_NOT_APPLICABLE
                  - MISSING_IDENTIFIER
                  - UNNECESSARY_IDENTIFIER
          examples:
            GENERIC_422_SERVICE_NOT_APPLICABLE:
              description: Service not applicable for the provided identifier
              value:
                status: 422
                code: SERVICE_NOT_APPLICABLE
                message: The service is not available for the provided identifier.
            GENERIC_422_MISSING_IDENTIFIER:
              description: An identifier is not included in the request and the device or phone number identification cannot be derived from the 3-legged access token
              value:
                status: 422
                code: MISSING_IDENTIFIER
                message: The phone number cannot be identified.
            GENERIC_422_UNNECESSARY_IDENTIFIER:
              description: An explicit identifier is provided when a device or phone number has already been identified from the access token
              value:
                status: 422
                code: UNNECESSARY_IDENTIFIER
                message: The phone number is already identified by the access token.
    Generic403:
      description: Forbidden
      headers:
        x-correlator:
          $ref: '#/components/headers/x-correlator'
      content:
        application/json:
          schema:
            allOf:
            - $ref: '#/components/schemas/ErrorInfo'
            - type: object
              properties:
                status:
                  enum:
                  - 403
                code:
                  enum:
                  - PERMISSION_DENIED
          examples:
            GENERIC_403_PERMISSION_DENIED:
              description: Permission denied. OAuth2 token access does not have the required scope or when the user fails operational security
              value:
                status: 403
                code: PERMISSION_DENIED
                message: Client does not have sufficient permissions to perform this action.
    Generic429:
      description: Too Many Requests
      headers:
        x-correlator:
          $ref: '#/components/headers/x-correlator'
      content:
        application/json:
          schema:
            allOf:
            - $ref: '#/components/schemas/ErrorInfo'
            - type: object
              properties:
                status:
                  enum:
                  - 429
                code:
                  enum:
                  - TOO_MANY_REQUESTS
          examples:
            GENERIC_429_TOO_MANY_REQUESTS:
              summary: Generic Too Many Requests
              description: Access to the API has been temporarily blocked due to rate or spike arrest limits being reached
              value:
                status: 429
                code: TOO_MANY_REQUESTS
                message: Rate limit reached.
    Payment2StepPrepareInvalid400:
      description: "Invalid input.\nCommon INVALID_ARGUMENT scenarios usually are:\n  - Schema validation failed (\"code\": \"INVALID_ARGUMENT\",\"message\": \"Client specified an invalid argument, request body or query param.\").\n  - paymentId is required (\"code\": \"INVALID_ARGUMENT

# --- truncated at 32 KB (63 KB total) ---
# Full source: https://raw.githubusercontent.com/api-evangelist/open-gateway/refs/heads/main/openapi/open-gateway-two-step-payment-api-openapi.yml