This plugin's implementation of CardPaymentService is incomplete about hybris HOT 4 CLOSED

Hi @alanktwong,

Thanks for reaching us. I'll try to answer to the questions you have raised.

First of all, if you look at the worldpayCommandFactory spring definition, you can see which commands have been implemented in the plugin.

The CaptureCommand and PartialCaptureCommand have the same implementation provided inside DefaultWorldpayCaptureCommand. Same method can be used for full or partial capture.

SubscriptionAuthorizationCommand has been provided in DefaultWorldpayTokenisedAuthorizationCommand

EnrollmentCheckCommand implementation has not been provided.
StandaloneRefundCommand implementation has not been provided.

CreateSubscriptionCommand - we subscribe (tokenise the card) as part of our CSE/HPP payment flow in our plugin implementation as this has been deemed as the most common scenario.

UpdateSubscriptionCommand - we automatically update the subscription during the payment flow (tokenisation) if some of the tokenised card details have changed.

GetSubscriptionDataCommand implementation has not been provided.

DeleteSubscriptionCommand implementation has not been provided although we do remove the tokens when a user decides to close the account.

The scope of the plugin is to provide a starting point to the SI on which it can implement additional functionalities or change the provided ones easily. There are many customisations that are project-dependant (like standalone refunds - not everyone wants them) and those have been omitted.

Certainly, based on your feedback, we can re-evaluate the scope and decide to provide more implementations.

from hybris.

Thanks for the reply. Knowing that an implementation has been wired in for partial capture is helpful.

What code does the notification API expect for partial capture? We'd like to support a use case where there is 1 authorization (so the notification callback URL should expect the order code to identify the transaction), but a partial capture per consignment as each consignment is shipped.

If we use the plugin OOTB, the notification API won't support this naturally because the notification callback URL will identify the capture transaction by the consignment code (not the order code).

Is there a way for us to use a common identifier for authorizations and all of the partial captures for the notification callbacks?

from hybris.

@alanktwong Just to clarify, the plugin itself does not support a multiple capture because it's built on top of the accelerator which ootb just creates and ships one consignment. Worldpay, however, does support multiple captures but the onus to handle it is on you. This is, as said previously, because every project has its own requirements and business logic.

If we use the plugin OOTB, the notification API won't support this naturally because the notification callback URL will identify the capture transaction by the consignment code (not the order code).

I don't think this is correct. The plugin uses the order code when performing a capture which means you will receive the order code in the notification.

from hybris.

Thanks @rselimi . We will proceed as discussed to take advantage of the worldpayOrderCode on the AbstractOrderModel that was added by the plugin to be sure of the identity of the notification callbacks.

Using de.hybris.platform.payment.PaymentService.partialCapture(PaymentTransactionModel transaction, BigDecimal amount)should be good enough to trigger the capture command you've already noted.

from hybris.