bluem-development / bluem-php Goto Github PK

In the Bluem API the DebtorReference has a restriction on the length (max 35) but not on the allowed characters.
The library is converting the DebtorReference to alphanumeric only while the API allowes whitespaces and special chars.

Hi,

I was a bit confused regarding the way this library is versioned. Recently there was a "major" update (DaanRijpkema@bd8ce95) from 2.0.x to 2.1.x containing some breaking changes. When breaking changes are introduced the versioning should have been updated to 3.0.x. Please try to use the semantic versioning standard (https://semver.org/) to prevent these sudden surprises when updating only a minor version.

Thanks in advance.
Nico

Currently it is not possible to provide a BrandId in the request to create a payment. As far as I see is it missing in all requests.
It should be part of RequestAttributes which is not implemented in any request.

The update to version 2.3.2.4 breaks the iban name check. The IBANNameCheckBluemResponse GetNameResult returns empty string.

We think that's because the GetNameResult calls getKeyFromIBANCheckResult with one parameter. And the second one is then null. The second one get's passed to the getIBANCheckResultObject as a parameter $parentObjectKey. This causes $parent->{$parentObjectKey} empty check to be true.

Since version 2.3.2.4 our PHP unit test are failing.
We are running PHP8.1

PHP Fatal error:  Declaration of Bluem\BluemPHP\Validators\WebhookXmlValidation::validate(SimpleXMLElement $data): Bluem\BluemPHP\Validators\WebhookXmlValidation must be compatible with Bluem\BluemPHP\Validators\WebhookValidator::validate($data): Bluem\BluemPHP\Validators\WebhookValidator in .../vendor/bluem-development/bluem-php/src/Validators/WebhookXmlValidation.php on line 26
In WebhookXmlValidation.php line 26:
                                                                               
  Declaration of Bluem\BluemPHP\Validators\WebhookXmlValidation::validate(Sim  
  pleXMLElement $data): Bluem\BluemPHP\Validators\WebhookXmlValidation must b  
  e compatible with Bluem\BluemPHP\Validators\WebhookValidator::validate($dat  
  a): Bluem\BluemPHP\Validators\WebhookValidator    

$this->paymentReference = "$this->debtorReference$this->transactionID";

DebtorReference has to be maximal 35 characters long
TransactionID has to be alphanumeric and maximal 64 characters long and is set by the library by the first 28 characters of DebtorReference plus YYYYMMDD
PaymentReference has to be alphanumeric and maximal 35 characters long

So, given this example:
DebtorReference = "Website order 12345678";
The library is removing all the non-alphanumeric values from the DebtorReference (#20) (why?).

TransactionID will be "Websiteorder1234567820220906";
PaymentReference will be "Websiteorder12345678Websiteorder1234567820220906";

The PaymentReference is a combination of a max 35 long string and a max 36 long string, but can only be 35 chars long and will throw a validation error from the API.

Expected behaviour is that PaymentReference can be set by the implementation (and will be validated) or otherwise will be a valid generated value which meets the API requirements.

We are implementing the IBAN-Name check feature with this package in a Laravel application.

When there is a special character in de name we get an error reponse. The errror is:

Error: Request is not formed correctly. More details: Error 26 in  (Line: 12):Entity 'eacute' not defined;

The name we use in Hénk de Vries.

If we have a look in de IBANBluemRequest the iban and name are sanitized and converted to html entities:

If we remove the htmlentities the request is formed correctly.

Only problem with the response now is dat the AssumedName is Hénk de Vries. Its looks like something is wrong with the utf-8 encode or decoding. In the PerformRequest function you can see that the request values get utf8_encode, but the response never gets decoded.

Example repo to reproduce problem: https://github.com/jhhazelaar/laravel-bluem-htmlentities-encoding

Currently you can only create a payment transaction with an ideal debtorWallet while Bluem also supports creditcard and paypal.

The CVS/CVV of a creditcard can start with a leading zero.
The library is using property type integer for the security number, which can not handle valid values like '012'.

When you create a payment without payment method, by default iDEAL is used without a BIC. That all works well.
When you set setPaymentMethodToIDEAL you have to define a BIC otherwise you'll get an validation error.

Because Bluem works without defining a BIC (you'll get the bank selection screen) the expected behaviour is that setPaymentMethodToIDEAL can be called without a BIC.

Would it be possible to allow setting the webhook url alongside creating the payment transaction?

As I am working with a local environment, test environment and acceptance environment, the webhook url domain changes per environment so it would be nice and time-saving if it would be possible to set this through the payment creation transaction without having to get in contact via email every time for the url change.

When you create a PaymentBluemRequest, a $transactionID is generated (CreatePaymentTransactionID).
But that TransactionID doesn't make any sense because Bluem generates its own transactionID.

So the self generated TransactionID is added (together with the entranceCode) to the debtorReturnURL but on the return page you can't do anything with the transactionID because it doesn't match the transactionID known by Bluem.