nexylan / paybox-direct Goto Github PK

Hello

Paybox' doc says that SITE, RANG and NUMQUESTION are always returned unchanged in the response, and their values must be the same than in the request.

Quote (sorry, french):

Les variables SITE, RANG et NUMQUESTION sont toujours répétées identiques à l’appel afin
de bien identifier à quoi correspond la question. Ces valeurs devront être contrôlées
systématiquement.

Source, page 12 : https://www.paybox.com/wp-content/uploads/2021/10/ManuelIntegrationVerifone_PayboxDirect_V8.2_FR.pdf

I suggest to introduce that check in order to consider a response valid or not.
Actually, this check is not possible outside the library, because the generated questionNumber is private and incremented after each request.

http://docs.php-http.org/

See also: http://docs.php-http.org/en/latest/httplug/library-developers.html

Link: https://github.com/greg0ire/enum

Discussion ref: #12 (comment)

Those parameters would not exist on exception response.

The readme states 5.6 but composer says 7.4

Is 7.4 really needed or would it work fine on any 7.x?

Would expect backwards compatability to be possible with the right combination of dependency versions.
Or if not would you be open to me building a branch with full 7.x support?

Implement psr/log for logging.

See also how can we integrate it with monolog for Symfony projects.

Try to remove magic calls on PayboxResponse and do abstraction like on request classes.

On documentation, it says that DEVISE is mandatory for some operation.

But if we try without this parameter (example: authorize), this works.

Test:

• What happen on BO without the parameter
• What happen if we send the same as the default one
• What happen if we send a different one (e.g. dollar)

Find a way to auto detect best http client to use if not provided and throw a proper exception if not found.

And make PayboxException heriting directly from \RuntimeException.

Ref #12.

If would be nice to be able to see the response object when an exception is displayed. Not sure if it should be part of the message or rather be a property of the exception, and have this property be nicely displayed by some framework integration class.

When logging the exception, this property should be added to the $context argument.

Ref #12.

Affected people are probably not the same depending on the origin of the exception.

• It the exception comes from the merchant, developers are affected, because the code probably needs to be changed
• If the exception comes from the gateway, the application should display a 502 or maybe a 503, beacuse it is probably an outage from paybox
• If the exception comes from the bank, the financial department probably needs to be aware of that.

Likewise, error in code and validation problems should be segregated. Ideally validation problems should only happen on the merchant side, but it could happen further down the chain in case of suspicious activity of the cardholder, for example.

Here is how I organised that:

Exception
├── Error
│   ├── BankErrorException.php
│   ├── GatewayErrorException.php
│   └── MerchantErrorException.php
├── ErrorException.php
├── Validation
│   ├── BankValidationException.php
│   ├── GatewayValidationException.php
│   └── MerchantValidationException.php
├── ValidationException.php
├── Wallet
│   └── CardNotFoundException.php
└── WalletException.php

If set to true with production flag also to true, use the API_URL_RESCUE as base url.