paddlehq / paddle-php-sdk Goto Github PK

Describe the bug

I am encountering an Error 500 when trying to list products using the Paddle PHP SDK in the Sandbox environment. The API key is validated, and the client seems to be implemented correctly. The issue arises when calling $client->products->list(); which triggers an error from the Paddle API.

{
  "type": "https://tools.ietf.org/html/rfc2616#section-10",
  "title": "An error occurred",
  "status": 500,
  "detail": "Paddle API can't process your request"
}

Steps to reproduce

1. Implement the Paddle PHP SDK.
2. Initialise client with API KEY and in Sandbox.
3. Execute the command $client->products->list();.

Expected behavior

A successful API call returning a list of products.

Code snippets

	// Initialize the API
	$this->api = new Client(
		$this->params->get('app.paddle')['api_key'],
		new Options(
			$this->params->get('app.paddle')['is_sandbox'] ?
				Environment::SANDBOX :
				Environment::PRODUCTION
		),
		$this->asyncClient,
	);

	$this->api->products->list();

PHP version

PHP 8.1

SDK version

0.1.0

API version

V1

Additional context

Investigation and Findings

• Debugging revealed that the GET request to 'https://sandbox-api.paddle.com/products' was correctly formatted but included an unusual string "null" in the request body, which is atypical for GET requests.
• Manually resending the request using Paw/Postman with the string "null" in the body reproduces the error, confirming its role in the issue.
• I have traced the problem to this line of code: Line 179 in Client.php. It appears that even if the $payload is null, the serialization process converts it to a string "null", which is then incorrectly included in the GET request body.

Possible Cause

The method of serializing the payload in the SDK seems to convert a null value into a string "null", which is then included in the body of the GET request. This behavior is not standard for GET requests and could be causing the Paddle API to return an error.

Suggested Fix

Review and modify the serialization process in the SDK to ensure that a null payload does not result in a string "null" being included in the GET request body. It might involve adding a condition to check if the payload is null before serializing it. This change could prevent the inclusion of inappropriate data in the GET request body, potentially resolving the error.

===

P.s.: Thank you for this SDK. It comes just in time! I've already seen myself having to implement a PHP client myself in the next few weeks. 👍

Describe the bug

Dear team,

we use the SDK to verify webhooks and it works for 99% of the cases.
For the failing ones we noticed that the customer have special characters e.g. in the customer name (e.g Ü Ä Ö for German customers or Å/å) and the validation fails.

We added a unit test for these payloads and its reproducible - but we cant share it because it contains customer data.

How can we validate in these cases?

Thanks,
Max

Steps to reproduce

Added the following test with a vailing JSON payload.
Also tested it with a valid one to ensure that the code works.

Expected behavior

Webhook validation successful

Code snippets

/** @test */
        public function it_verifies_a_signature2(): void
        {
            $json = '<PAYLOAD WITH SPECIAL CHARACTERS>';

            $request = Psr17FactoryDiscovery::findRequestFactory()
                ->createRequest('POST', '/paddle/notifications')
                ->withHeader(
                    PaddleSignature::HEADER,
                    '<header>',
                )
                ->withBody(
                    Psr17FactoryDiscovery::findStreamFactory()->createStream($json),
                );
    
            $secrets = [
                // The correct key
                new Secret('<KEY>'),
            ];
    
            self::assertTrue((new Verifier(null))->verify($request, ...$secrets));
        }

### PHP version

PHP 8.2.7

### SDK version

latest

### API version

version 1

### Additional context

I can share the json payload / key via email if needed: firstname@lastname dot it

Describe the bug

Im using PaddleJS in Frontend and store the current Userrequest in Backend (SPA - Approach), by validating the Transaction_ID. I realized I get different kind of Transaction Status by Paddle, when Client returns Status "Completed".

• Client - Paddle JS => response: { status: "completed" }
• Server - API Request "https://sandbox-api.paddle.com/transactions/{transaction_id}" => response: { status: "paid" }

Steps to reproduce

1. Client: Paddle JS Process Checkout
2. Client -> Server Request: Each Response will be sent to Backend via API Call
3. Server: Validate Client Request by Paddle Request "https://sandbox-api.paddle.com/transactions/{transaction_id}"

Expected behavior

Response from Client & Server should have the same Status and according attributes

Code snippets

// Client Request
// As soon we get Paddle Callback, Serverrequest is starting
const paddleInstance = await initializePaddle({
     environment: 'sandbox',
     token: props['publicKey'],
     eventCallback: function(data) {
         context.emit('paddleEvents', data)
     }
});

// Server Request (PHP)
// Validate Client Request
$this->client = new Client([
    'verify' => (bool) env('PADDLE_SANDBOX') ? false : true,
    'base_uri' => env('PADDLE_URL'),
]);

$response = $this->client->request('GET', 'transactions/' . $transactionID, [
   'headers' => [
         'Authorization' => 'Bearer ' . $this->paddle_api_key
    ],
]);

PHP version

PHP 8.1

SDK version

paddle

API version

Paddle Version 1

Additional context

Its not directly correlated to https://github.com/PaddleHQ/paddle-php-sdk, but may you can help me, or you also faced this issue?