201 Respones Code, but Error in response parsing

[markus-gx]

Environment: Sandbox
Payment Type: EPS Payment (Austria)

Error:

The response did not match the response schema.

Some properties are missing in the object: "country_code".

Given value: {"national_number":"43158850"}
Type: 'object'
Expected type: 'Optional<Lazy<Object<{countryCode,nationalNumber}>>>'
Path: purchase_units › 0 › shipping › phone_number

  
  Some properties are missing in the object: "country_code".
  
  Given value: {"national_number":"43158850"}
  Type: 'object'
  Expected type: 'Optional<Lazy<Object<{countryCode,nationalNumber}>>>'
  Path: purchase_units › 0 › shipping › phone_number
  at new ResponseValidationError (node_modules/@apimatic/core/lib/errors/responseValidationError.js:22:24)
  at resInvalidErr (node_modules/@apimatic/core/lib/http/requestBuilder.js:508:16)
  at node_modules/@apimatic/core/lib/http/requestBuilder.js:510:68
  at validateJson (node_modules/@apimatic/core/lib/http/requestBuilder.js:515:15)
  at parseJsonResult (node_modules/@apimatic/core/lib/http/requestBuilder.js:510:12)
  at DefaultRequestBuilder.<anonymous> (node_modules/@apimatic/core/lib/http/requestBuilder.js:292:104)
  at step (node_modules/tslib/tslib.js:196:27)
  at Object.next (node_modules/tslib/tslib.js:177:57)
  at fulfilled (node_modules/tslib/tslib.js:167:62)
  at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

The error occurs only with EPS payment method. Payment via PayPal works.
The response is a 201 Status Code and based on the Paypal Debug Logs in the Web-Panel the response is correct.
Seems like the parser has a bug :)

Code which is failing:

 const collect = {
    id: orderId,
    prefer: 'return=minimal',
  }

  try {
    const { body } = await PaypalOrdersController.ordersCapture(collect) //Fail here. 

[LeonarthusMectus]

Hey @markus-gx

Thanks for the report! I don't think this is a bug in the parser, but instead an issue in the API spec we used. The API defines both the country_code & national_number values as required in the response, so the SDK requires them in the constructor, but the API appears to be dropping the country_code, creating the issue.

Turns out there are quite a few Phone number definitions in the APIs, and I think the Orders team may have used the wrong one given what we're seeing ;) I'm going to reach out to them to see if we can get this sorted out and get a patch pulled into the SDKs once they confirm the proper values.

[markus-gx]

Hey @LeonarthusMectus any updates here?

[dbondarchuk]

@LeonarthusMectus I'm having a similar issue with the production environment, where the response is 201, but result is following:

"message": "Some properties are missing in the object: \"id\".\n\nGiven value: {\"network\":\"STAR\"}\nType: 'object'\nExpected type: 'Optional<Lazy<Object<{id,date,network,acquirerReferenceNumber}>>>'\nPath: purchase_units › 0 › payments › captures › 0 › network_transaction_reference",

where the body as following:

"purchase_units": [
              {
                "reference_id": "default",
                "payments": {
                  "captures": [
                    {
                      "id": "REDACTED",
                      "status": "COMPLETED",
                      "amount": {
                        "currency_code": "USD",
                        "value": "40.00"
                      },
                      "final_capture": true,
                      "seller_protection": {
                        "status": "NOT_ELIGIBLE"
                      },
                      "seller_receivable_breakdown": {
                        "gross_amount": {
                          "currency_code": "USD",
                          "value": "40.00"
                        },
                        "paypal_fee": {
                          "currency_code": "USD",
                          "value": "1.45"
                        },
                        "net_amount": {
                          "currency_code": "USD",
                          "value": "38.55"
                        }
                      },
                      "links": [
                       ...
                      ],
                      "create_time": "2025-07-04T01:30:04Z",
                      "update_time": "2025-07-04T01:30:04Z",
                      "network_transaction_reference": {
                        "network": "STAR"
                      },
                      "processor_response": {
                        ... /// not sure if it is important
                      }
                    }
                  ]
                }
              }
            ],

[Dani-Kirby]

Hey @markus-gx and @dbondarchuk thanks for these reports. I can confirm we've been working on remedying these issues with the teams responsible for our API behavior and their associated API specifications. This should be remedied on our next release so we'll be reaching out at that time to confirm that you aren't encountering the same errors after updating.

Thanks again for your patience as we work through this.