APIs aligment with Transversal WGs Public Releases Fall25

code/API_definitions/carrier-billing-refund.yaml

@@ -438,11 +438,11 @@ components:
         refundCreationDate:
           type: string
           format: date-time
-          description: Date time when the refund 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).
+          description: Date time when the refund 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.
         refundDate:
           type: string
           format: date-time
-          description: Date time when the refund 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).
+          description: Date time when the refund 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.
         reason:
           type: string
           description: Reason provided to request the refund. Optionally provided by the user or the merchant.
@@ -590,7 +590,7 @@ components:
             accessTokenExpiresUtc:
               type: string
               format: date-time
-              description: REQUIRED. An absolute (UTC) timestamp at which the token shall be considered expired. Token expiration should occur after the expiration of the requested payment refund, allowing the client to be notified of any changes during the payment refund's existence. If the token expires while the payment refund is still active, the client will stop receiving notifications.
+              description: REQUIRED. An absolute (UTC) timestamp at which the token shall be considered expired. Token expiration should occur after the expiration of the requested payment refund, allowing the client to be notified of any changes during the payment refund's existence. If the token expires while the payment refund is still active, the client will stop receiving notifications. It must follow [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must have time zone.
             accessTokenType:
               description: REQUIRED. Type of the access token (See [OAuth 2.0](https://tools.ietf.org/html/rfc6749#section-7.1)).
               type: string
@@ -613,7 +613,7 @@ components:
             accessTokenExpiresUtc:
               type: string
               format: date-time
-              description: REQUIRED. An absolute (UTC) timestamp at which the token shall be considered expired. Token expiration should occur after the expiration of the requested payment refund, allowing the client to be notified of any changes during the payment refund's existence. If the token expires while the payment refund is still active, the client will stop receiving notifications.
+              description: REQUIRED. An absolute (UTC) timestamp at which the token shall be considered expired. Token expiration should occur after the expiration of the requested payment refund, allowing the client to be notified of any changes during the payment refund's existence. If the token expires while the payment refund is still active, the client will stop receiving notifications. It must follow [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must have time zone.
             accessTokenType:
               description: REQUIRED. Type of the access token (See [OAuth 2.0](https://tools.ietf.org/html/rfc6749#section-7.1)).
               type: string
@@ -812,7 +812,7 @@ components:
     DateTime:
       type: string
       format: date-time
-      description: Timestamp when the occurrence happened. Must adhere to RFC 3339.
+      description: Timestamp when the occurrence happened. It must follow [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must have time zone.
       example: "2023-11-03T12:27:10Z"
     EventRefundCompleted:
       description: Event structure for refund completed
@@ -848,7 +848,7 @@ components:
           properties:
             refundDate:
               type: string
-              description: Date when the refund 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).
+              description: Date when the refund 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.
               format: date-time
               example: "2023-11-03T12:27:08.312Z"
     RefundDenied:
@@ -898,19 +898,19 @@ components:
     ErrorInfo:
       type: object
       required:
-        - code
         - message
         - status
+        - code
       properties:
-        code:
+        message:
           type: string
-          description: Code given to this error
+          description: A human-readable description of what the event represents
         status:
           type: integer
           description: HTTP response status code
-        message:
+        code:
           type: string
-          description: Detailed error description
+          description: A human-readable code to describe the error
   responses:
     Generic400:
       description: Invalid input
@@ -1352,15 +1352,15 @@ components:
         type: integer
         default: 10
     StartRefundCreationDate:
-      description: Initial `refundCreationDate` for running the query. 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)
+      description: Initial `refundCreationDate` for running the query. It must follow [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must have time zone.
       in: query
       name: refundCreationDate.gte
       required: false
       schema:
         format: date-time
         type: string
     EndRefundCreationDate:
-      description: End `refundCreationDate` for running the query. 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)
+      description: End `refundCreationDate` for running the query. It must follow [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must have time zone.
       in: query
       name: refundCreationDate.lte
       required: false

code/API_definitions/carrier-billing.yaml

@@ -648,11 +648,11 @@ components:
         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).
+          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 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).
+          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
@@ -686,11 +686,11 @@ components:
         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).
+          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 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).
+          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
@@ -744,7 +744,7 @@ components:
             accessTokenExpiresUtc:
               type: string
               format: date-time
-              description: REQUIRED. An absolute (UTC) timestamp at which the token shall be considered expired. Token expiration should occur after the expiration of the requested payment, allowing the client to be notified of any changes during the payment's existence. If the token expires while the payment is still active, the client will stop receiving notifications.
+              description: REQUIRED. An absolute (UTC) timestamp at which the token shall be considered expired. Token expiration should occur after the expiration of the requested payment, allowing the client to be notified of any changes during the payment's existence. If the token expires while the payment is still active, the client will stop receiving notifications. It must follow [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must have time zone.
             accessTokenType:
               description: REQUIRED. Type of the access token (See [OAuth 2.0](https://tools.ietf.org/html/rfc6749#section-7.1)).
               type: string
@@ -767,7 +767,7 @@ components:
             accessTokenExpiresUtc:
               type: string
               format: date-time
-              description: REQUIRED. An absolute (UTC) timestamp at which the token shall be considered expired. Token expiration should occur after the expiration of the requested payment, allowing the client to be notified of any changes during the payment's existence. If the token expires while the payment is still active, the client will stop receiving notifications.
+              description: REQUIRED. An absolute (UTC) timestamp at which the token shall be considered expired. Token expiration should occur after the expiration of the requested payment, allowing the client to be notified of any changes during the payment's existence. If the token expires while the payment is still active, the client will stop receiving notifications. It must follow [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must have time zone.
             accessTokenType:
               description: REQUIRED. Type of the access token (See [OAuth 2.0](https://tools.ietf.org/html/rfc6749#section-7.1)).
               type: string
@@ -920,7 +920,7 @@ components:
         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).
+          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.
         validationInfo:
           allOf:
             - $ref: "#/components/schemas/ValidationInfo"
@@ -1249,7 +1249,7 @@ components:
     DateTime:
       type: string
       format: date-time
-      description: Timestamp when the occurrence happened. Must adhere to RFC 3339.
+      description: Timestamp when the occurrence happened. It must follow [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must have time zone.
       example: "2023-11-03T12:27:10Z"
     EventPaymentPendingValidation:
       description: Event structure for payment pending validation
@@ -1309,7 +1309,7 @@ components:
           properties:
             paymentDate:
               type: string
-              description: Date when the payment is effectively performed, both in 1-step and 2-step scenarios. 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).
+              description: Date when the payment is effectively performed, both in 1-step and 2-step scenarios. 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.
               format: date-time
               example: "2023-11-03T12:27:08.312Z"
     PaymentCancelled:
@@ -1354,19 +1354,19 @@ components:
     ErrorInfo:
       type: object
       required:
-        - code
         - message
         - status
+        - code
       properties:
-        code:
+        message:
           type: string
-          description: Code given to this error
+          description: A human-readable description of what the event represents
         status:
           type: integer
           description: HTTP response status code
-        message:
+        code:
           type: string
-          description: Detailed error description
+          description: A human-readable code to describe the error
   responses:
     Generic400:
       description: Bad Request
@@ -2225,15 +2225,15 @@ components:
         type: integer
         default: 10
     StartPaymentCreationDate:
-      description: Initial `paymentCreationDate` for running the query. 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)
+      description: Initial `paymentCreationDate` for running the query. It must follow [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must have time zone.
       in: query
       name: paymentCreationDate.gte
       required: false
       schema:
         format: date-time
         type: string
     EndPaymentCreationDate:
-      description: End `paymentCreationDate` for running the query. 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)
+      description: End `paymentCreationDate` for running the query. It must follow [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must have time zone.
       in: query
       name: paymentCreationDate.lte
       required: false

code/Test_definitions/carrier-billing-cancelPayment.feature

@@ -7,7 +7,7 @@ Feature: CAMARA Carrier Billing API, v0.5.0-rc.1 - Operation cancelPayment
   # Testing assets:
   # * A phone number eligible for payment (no restrictions for it to be used to perform a payment)
   #
-  # References to OAS spec schemas refer to schemas specifies in carrier-billing.yaml, version 0.5.0-rc.1
+  # References to OAS spec schemas refer to schemas specifies in carrier-billing.yaml
 
   Background: Common cancelPayment setup
     Given the resource "/carrier-billing/v0.5rc1/payments/{paymentId}/cancel"

code/Test_definitions/carrier-billing-confirmPayment.feature

@@ -8,7 +8,7 @@ Feature: CAMARA Carrier Billing API, v0.5.0-rc.1 - Operation confirmPayment
   # * A phone number eligible for payment (no restrictions for it to be used to perform a payment)
   # * A phone number not-eligible for payment (payment is denied for it due to business conditions)
   #
-  # References to OAS spec schemas refer to schemas specifies in carrier-billing.yaml, version 0.5.0-rc.1
+  # References to OAS spec schemas refer to schemas specifies in carrier-billing.yaml
 
   Background: Common confirmPayment setup
     Given the resource "/carrier-billing/v0.5rc1/payments/{paymentId}/confirm"

code/Test_definitions/carrier-billing-createPayment.feature

@@ -8,7 +8,7 @@ Feature: CAMARA Carrier Billing API, v0.5.0-rc.1 - Operation createPayment
   # * A phone number eligible for payment (no restrictions for it to be used to perform a payment)
   # * A phone number not-eligible for payment (payment is denied for it due to business conditions)
   #
-  # References to OAS spec schemas refer to schemas specifies in carrier-billing.yaml, version 0.5.0-rc.1
+  # References to OAS spec schemas refer to schemas specifies in carrier-billing.yaml
 
   Background: Common createPayment setup
     Given the resource "/carrier-billing/v0.5rc1/payments"

code/Test_definitions/carrier-billing-preparePayment.feature

@@ -8,7 +8,7 @@ Feature: CAMARA Carrier Billing API, v0.5.0-rc.1 - Operation preparePayment
   # * A phone number eligible for payment (no restrictions for it to be used to perform a payment)
   # * A phone number not-eligible for payment (payment is denied for it due to business conditions)
   #
-  # References to OAS spec schemas refer to schemas specifies in carrier-billing.yaml, version 0.5.0-rc.1
+  # References to OAS spec schemas refer to schemas specifies in carrier-billing.yaml
 
   Background: Common preparePayment setup
     Given the resource "/carrier-billing/v0.5rc1/payments/prepare"

code/Test_definitions/carrier-billing-refund-createRefund.feature

@@ -8,7 +8,7 @@ Feature: CAMARA Carrier Billing Refund API, v0.3.0-rc.1 - Operation createRefund
   # * A phone number eligible for payment & refund (no restrictions for it to be used to perform a payment or refund)
   # * A phone number not-eligible for refund (refund is denied for it due to business conditions)
   #
-  # References to OAS spec schemas refer to schemas specifies in carrier-billing-refund.yaml, version 0.3.0-rc.1
+  # References to OAS spec schemas refer to schemas specifies in carrier-billing-refund.yaml
 
   Background: Common createRefund setup
     Given the resource "/carrier-billing-refund/v0.3rc1/refunds"

code/Test_definitions/carrier-billing-refund-retrievePaymentRemainingAmount.feature

@@ -8,7 +8,7 @@ Feature: CAMARA Carrier Billing Refund API, v0.3.0-rc.1 - Operation retrievePaym
   # * A phone number eligible for payment & refund
   # * Several payments refunds performed in different situations (total and partial)
   #
-  # References to OAS spec schemas refer to schemas specifies in carrier-billing-refund.yaml, version 0.3.0-rc.1
+  # References to OAS spec schemas refer to schemas specifies in carrier-billing-refund.yaml
 
   Background: Common retrievePaymentRemainingAmount setup
     Given the resource "/carrier-billing-refund/v0.3rc1/payments/{paymentId}/refunds/remaining-amount"

code/Test_definitions/carrier-billing-refund-retrieveRefund.feature

@@ -8,7 +8,7 @@ Feature: CAMARA Carrier Billing Refund API, v0.3.0-rc.1 - Operation retrieveRefu
   # * A phone number eligible for payment & refund
   # * Several payments and refunds performed in the environment (at least 10 for each of them)
   #
-  # References to OAS spec schemas refer to schemas specifies in carrier-billing-refund.yaml, version 0.3.0-rc.1
+  # References to OAS spec schemas refer to schemas specifies in carrier-billing-refund.yaml
 
   Background: Common retrieveRefund setup
     Given the resource "/carrier-billing-refund/v0.3rc1/payments/{paymentId}/refunds/{refundId}"