Checkout-PHP-SDK | PHP SDK for Checkout RESTful APIs | SDK library

Each of your routes (the create route, and the capture route) must return a response that is a JSON string, and no other text nor HTML. print_r is not suitable.

I would assume the reference_id is something we generate ourselves

Yes, that appears to be the case.

If you look under https://developer.paypal.com/docs/api/orders/v2/#definition-purchase_unit, there it says,

reference_id - string - The API caller-provided external ID for the purchase unit.

So you, as the caller of the API, have to provide this ID.

When PayPal processes payments, any information about the funding source -- including the billing address -- is kept private to payers' accounts. This is a reason to prefer using PayPal to make payments on random websites, as that information is kept private by design and cannot be compromised.

Only shipping information (if applicable) is provided in the response.

If you need more billing information from customers, you can collect it yourself. Or if you are a large merchant who habitually collects this information, you can ask PayPal to include it in their API responses and they may consider such a request from a reputable company with established business history, but it will not be there normally.

As explained in comments, you can't change the redirect method back from PayPal. It will always be a GET string appended to your return_url.

However, the ideal and recommended solution is to not use any redirects. At all. Instead, use the PayPal-Checkout-SDK you have to make two routes on your server, one for 'Create Order' and one for 'Capture Order', documented here, that return only JSON data (no HTML or text). The latter one should (on success) store the payment details in your database before it does the return (particularly purchase_units[0].payments.captures[0].id, the PayPal transaction ID)

Pair these two JSON-only routes with the following approval flow that does not use any redirects, and instead keeps your site loaded in the background (lightboxed) at all times during payment approval: https://developer.paypal.com/demo/checkout/#/pattern/server

A 500 error within your /createOrder route is something you'll need to diagnose/debug internally. Try loading the URL in a browser and see if you get any more error output from Laravel. If you don't, edit the corresponding PHP to output more useful information about what's going on.

Once you sort that out and are returning an actual id as part of a JSON object, you need to change your front end code to read the key of that id. It looks like you are reading the key orderID, which won't be set unless you specifically set it.

The following front-end demo code is better, and has error handling: https://developer.paypal.com/demo/checkout/#/pattern/server

This part of your front-end code:

Install it in a local environment, do your development and test that it works, then FTP all the files over

No, there isn't; the checkout to each receiver must be separate.

The APIs and checkout flows that used to be able to do that type of checkout (EC Parallel Payments and Adaptive Payments) are old and deprecated. Do not use them.

The payee object array is still in the wrong place. Does this adjusted sample work for you? (not tested)

It was an error with curl_setopt( $handle, CURLOPT_CAINFO, null). It was not sertificated... in official sdk, i downloaded cacert.pem file and switched its path with null and now is working when CURLOPT_SSL_VERIFYPEER is set to true.