search

pronamic / wp-pronamic-pay-adyen

Adyen driver for the WordPress payment processing library.
https://www.wp-pay.org/gateways/adyen/
6 stars 2 forks source link

Auto submit versus show pay button #9

Closed remcotolsma closed 2 years ago

remcotolsma commented 2 years ago

In https://github.com/pronamic/wp-pronamic-pay-adyen/pull/8 I initially removed the auto submit and showPayButton functionality. In the review from @rvdsteege was suggested to add this again:

Reüel

Re-add auto submit functionality in checkout-drop-in.js and set $configuration['showPayButton'] = false; here if only a single payment method from the below listed methods will be shown in drop-in.

$auto_submit_methods = array(
  PaymentMethodType::SWISH,
  PaymentMethodType::TWINT,
  PaymentMethodType::VIPPS,
  PaymentMethodType::UNIONPAY,
);

Previously in checkout-drop-in.js: https://github.com/pronamic/wp-pronamic-pay-adyen/blob/f48c76409c12b29927f5974d12d0c98361bbb9bf/js/src/checkout-drop-in.js#L130-L136

This avoids customers needing to select the payment method twice (e.g. in WooCommerce checkout and one more time in drop-in, even though there are no additional input fields for these methods in drop-in).

Remco

How do we know for sure that the dropin doesn't want to show additional input fields for these methods? Maybe no additional fields are shown now, but by using the dropin this can change? If no additional input is needed, can we use a direct payment flow via the /payments endpint?

Reüel

As discussed at Pronamic HQ, we could keep the pay button and try to submit drop-in for these methods. If additional input is needed in the future, this should then result in input validation errors (before the transaction is started at Adyen). Previously, we were also hiding the pay button to prevent duplicate transactions for a single payment, but that is handled differently now with the sessions implementation.

Swish Country Code: SE Currency: SEK

The Swish payment flow uses a QR code (desktop) or a redirect to the Swish app (redirect URL with swish:// protocol). Drop-in can handle this for us.

FYI, if I just start a Swish payment via the API integration, the following error occurs:

The handling of the Pending result code is not implemented.

TWINT Country Code: CH Currency: CHF

Seems to work with our API integration, with RedirectShopper result code.

Vipps Country Code: NO Currency: NOK

Seems to work with our API integration, with RedirectShopper result code.

China UnionPay I can't remember how this one ended up in the auto-submit list. Seems to work fine with drop-in, without additional input fields. However, with our API integration, I get the following error message:

交易失败 [9200003]Empty req.

I'd suggest just using drop-in for this payment method.

We still have to process the above in https://github.com/pronamic/wp-pronamic-pay-adyen/pull/8.

remcotolsma commented 2 years ago

The error Error validating /redirect/method was caused by a required parameter method in https://github.com/wp-pay-gateways/adyen/blob/1d4763d1f554992c324ebedd1b0a1fb680dff858/json-schemas/redirect.json — I've removed this parameter in https://github.com/wp-pay-gateways/adyen/commit/454a25ec153f6dd9e96d25a9951287375442188e as this parameter is not always available apparently — for example with the Swish payment method.

After that change, the payment was started correctly via the direct API integration. However, this now resulted in an URL with a custom protocol (something like swishapp://) to redirect to the Swish app. That should work if the Swish app is installed on mobile, but can not be handled on desktop. Therefore, I've updated the Swish payment method to use the drop-in.

Using the drop-in results in a single payment method on the payment page and needs an extra click to submit the payment form, which is confusing as the payment method had already been selected during checkout/on the form. That is why I'm not showing the submit button with showPayButton: false (see https://docs.adyen.com/online-payments/web-drop-in/optional-configuration#optional-drop-in-configuration) and auto-submit the drop-in for this payment method. The QR code will now be shown without any further user interaction needed.

Alternatively, we could use the API integration and need to display the QR code ourselves, instead of handling this through the drop-in.

Originally posted by @rvdsteege in https://github.com/pronamic/wp-pronamic-pay/issues/276#issuecomment-963959937

remcotolsma commented 2 years ago

Swish Country Code: SE Currency: SEK

The Swish payment flow uses a QR code (desktop) or a redirect to the Swish app (redirect URL with swish:// protocol). Drop-in can handle this for us.

FYI, if I just start a Swish payment via the API integration, the following error occurs:

The handling of the Pending result code is not implemented.

This one is added to the auto submit list:

https://github.com/pronamic/wp-pronamic-pay-adyen/blob/6a2fd0b64f355d0dca473d0f92491871eae9c9c3/src/Gateway.php#L423-L439

TWINT Country Code: CH Currency: CHF

Seems to work with our API integration, with RedirectShopper result code.

This one is added to the API only list:

https://github.com/pronamic/wp-pronamic-pay-adyen/blob/6a2fd0b64f355d0dca473d0f92491871eae9c9c3/src/Gateway.php#L174-L208

Vipps Country Code: NO Currency: NOK

Seems to work with our API integration, with RedirectShopper result code.

This one is added to the API only list:

https://github.com/pronamic/wp-pronamic-pay-adyen/blob/6a2fd0b64f355d0dca473d0f92491871eae9c9c3/src/Gateway.php#L174-L208

China UnionPay I can't remember how this one ended up in the auto-submit list. Seems to work fine with drop-in, without additional input fields. However, with our API integration, I get the following error message:

交易失败 [9200003]Empty req.

I'd suggest just using drop-in for this payment method.

This one is added to the auto submit list:

https://github.com/pronamic/wp-pronamic-pay-adyen/blob/6a2fd0b64f355d0dca473d0f92491871eae9c9c3/src/Gateway.php#L423-L439

@rvdsteege How is this looking?

rvdsteege commented 2 years ago

Perfect 👌

Even better than expected: I tested auto submit with a payment method type which does have input fields in drop-in and it seemed the input validation errors which we expected (if additional input fields are added in the future) don't occur (initially at least; if you switch methods the errors will occur, but usually it won't be possible to switch methods in this scenario, as there should only be one method listed — I tried with scheme payment method type, which results in multiple methods in drop-in).