Use amount model in requests

[Robertbaelde]

This PR enables the usage of the Amount object in OrderCreate, OrderCapture and TransactionRefund requests.

This issue was already mentioned here: #22 (comment) and I think its a great idea to make these parts of the library more explicit. The setAmount setters still allow floats to be passed as well.

$request->setAmount(Amount::fromFloat(5.3, 'EUR'));

It also adds explicit helpers in the Amount object, to construct it from float or from cents.

$amount = Amount::fromCents(12345); // default currency = 'EUR'
$amount = Amount::fromFloat(123.45, 'USD');

Ideally in the future I'd love this package to support the two most commonly used money objects:

• https://github.com/brick/money
• https://github.com/moneyphp/money

But I think adding them as dependencies might not be desired. For now accepting an Amount class that can be extended, allows the client to at least implement an own Amount object that can transform external money objects.

[rikgirbes]

Yes! Awesome.

I personally wouldn't mind the dependency on MoneyPHP.
But oh well.

If we're going this route, we should also update the https://github.com/paynl/sdk-alliance repo.

@woutse what do you think?

[Robertbaelde]

I personally wouldn't mind the dependency on MoneyPHP.

Not sure what the implications are. Some packages are inline included (https://github.com/paynl/php-sdk/tree/main/src/Packages), which is quitte a weird pattern tbh.

If we're going this route, we should also update the https://github.com/paynl/sdk-alliance repo.

This repo works together with the old php sdk (https://github.com/paynl/sdk), so think thats not relevant.

I would love to see this SDK to get more feature complete with the available endpoints though.

[rikgirbes]

which is quitte a weird pattern tbh.

Yeah, it’s a strange pattern. Adding them with explicit versions in composer.json makes a lot more sense.

This repo works together with the old php sdk (https://github.com/paynl/sdk), so think thats not relevant.

True, but it’s currently the only repo that supports submerchant operations (updating submerchants, checking balances, requesting clearings, etc.). Still, now that you mention it, the better approach would be to update it to use the newer SDK...