Send order ID and/or payment ID to Paybox/Up2Pay (admin choice)

I've been looking further in the code, and this PBX_CMD is sent back to Drupal through a callback, to validate or not the payment entity once payment is processed on Paybox side. To do so, payment ID is mandatory.
It's a bit more complicated than I expected at first, as we need to handle this return in 3 different parts.

I've tried to serialize() or json_encode() an array to send both payment and order ids, then extract the data using unserialize() or json_decode(), but it's not working for now.
I'm able to load the payment entity on the callback, but it's the signature check which is failing..

\Drupal\commerce_paybox_payment\Plugin\Commerce\PaymentGateway\Paybox::onReturn

    if (!$payment instanceof PaymentInterface) {
      \Drupal::logger('commerce_paybox_payment')->debug('Check instanceof PaymentInterface failed');
      throw new PaymentGatewayException('Payment cannot be found');
    }

Exception message should be more explicit also.

If anybody has an advice.
I'll keep trying on my side.

OK, it seems that signature is not checkable or so based on some special characters. So I've restricted the separator option to - and _ only.
Seems OK so far.

My concern is on the API side.
payment_return.access_checker service and the API controller: they both get the Ref data from the request, but as payment has not been loaded at this point, I'm wondering how I'd be able to load the gateway config to know how to process this Ref data ?
Any lead ?

Also, di you have an example of where/how this API part code is used ?

That's one way to get this plugin config. But as you said, it would be safe only if there is only one Paybox payment gateway.

What about this : storing these two options in a global config for commerce_paybox_payment module, by modifying a bit the plugin config form build and submit methods.

• Pro: it would be accessible even if we don't know about current payment.
• Con: if user decides to set up 2 paybox gateways or more, they would all have the same config for this PBX_CMD / Ref mapping & separator setting.

OK, I ve just pushed a another commit to make mapping and separator config global, using config_factory.
So you don't get to load all paybox gateway to get config in the accessChecker.

Though, I still have some questions :

• why do you need to set the Ref at the end of the \Drupal\commerce_paybox_payment\Access\PaymentReturnAccessCheck::access method() ?
• what about the \Drupal\commerce_paybox_payment\Controller\PaymentController::return() method ? It's still getting the payment id directly from "Ref", without any processing..

I think the better way would be to have a service PbxCmdRefHelper or similar, providing two methods:

• one to build PBX_CMD value to post it
• one to process Ref value from request

We could use this service in both 3 classes :

• \Drupal\commerce_paybox_payment\Plugin\Commerce\PaymentGateway\Paybox
• \Drupal\commerce_paybox_payment\Access\PaymentReturnAccessCheck
• \Drupal\commerce_paybox_payment\Controller\PaymentController

Service is provided and instanciated in the 3 classes as we were discussing last week.
I've also add a mention about global config for entity mapping and separator, in the README file.

OK for me.
All the tests I've been running manually were also OK.

Hey !
Not that I want to re-open this issue, but I've figured out a way to get the payment id without having to get a global config for the separator and so..
To implement a manual payment from admin UI, I've created routes for Paybox callback, including both order and payment as parameters.
Something like that could be applied to the gateway method onReturn and onCancel. Not sure though, as I'm not sure of the route those two methods "answer" ?
And also for the IPN return callback (definitely, as it is a custom route)

Any thoughts ?

Actually, I think I was missing something.
Routes that are using onReturn and onCancel methods (also onNotify) are not custom routes, and payment ID is definitely not including as route parameters. So my last idea is not applicable in that case. Just nevermind ;)

---------

Though, there is one thing I read in the Drupal Commerce doc, making me wondering: why are you creating the payment entity before going to the offsite payment form.
It is definitely not recommended by Drupal Commerce documentation : https://docs.drupalcommerce.org/commerce2/developer-guide/payments/creat...

Maybe we should open a new issue/thread to discuss that matter instead of polluting this one, which is closed.