orderModificationProcessorJobPerformable is using worldpayOrderModificationProcessService for the constructor-arg but it should use it's alias to allow for custom extensions, based on worldpaynotifications to override the logic without the need of changing any of the worldpaynotifications code.

    <bean id="orderModificationProcessorJobPerformable" class="com.worldpay.cronjob.OrderModificationProcessorJobPerformable" parent="abstractJobPerformable">
        <constructor-arg name="worldpayOrderModificationProcessService" ref="worldpayOrderModificationProcessService"/>
    </bean>

should be changed to:

    <bean id="orderModificationProcessorJobPerformable" class="com.worldpay.cronjob.OrderModificationProcessorJobPerformable" parent="abstractJobPerformable">
        <constructor-arg name="worldpayOrderModificationProcessService" ref="orderModificationProcessStrategy"/>
    </bean>

This plugin's implementation of CardPaymentService is incomplete, given that 8 out of 12 logically possible commands are absent from worldpayapi. See https://github.com/Worldpay/hybris/tree/master/hybris/bin/y-ext/ext-worldpay/worldpayapi/src/com/worldpay/commands/impl

The commands whose implementation appear to be absent are:

• SubscriptionAuthorizationCommand
• PartialCaptureCommand
• EnrollmentCheckCommand
• StandaloneRefundCommand
• CreateSubscriptionCommand
• UpdateSubscriptionCommand
• GetSubscriptionDataCommand
• DeleteSubscriptionCommand

The business impact as far as I can tell are:

• If a merchant wants to have split payment captures for a single authorization, then their implementation partner will have to implement PartialCaptureCommand
• If a merchant wants to have saved cards via a subscription, then their implementation partner will have to implement SubscriptionAuthorizationCommand, CreateSubscriptionCommand, UpdateSubscriptionCommand, GetSubscriptionDataCommand, DeleteSubscriptionCommand
• If a merchant wants to have good will refunds, then their implementation partner will have to implement StandaloneRefundCommand

Hello again, worldpay team, we've encountered another issue with the latest 1905_7.0 release:

When the new DefaultWorldpayOrderModificationProcessService has been introduced, a class cast has creeped out of the if branch on this line. This causes an unhandled ClassCastException which crashes the OrderModificationProcessorJobPerformable completely and orders are stuck in Pending Payment Notification status.

Here is a unit test which you can add to DefaultWorldpayOrderModificationProcessServiceTest to reproduce the issue:

@Test
public void processOrderModificationMessages_WhenWorldpayOrderCodeRelatesToCartWithAuthorizationTransactionType_ShouldDoNothing() throws WorldpayConfigurationException {
    when(paymentTransactionModelMock.getOrder()).thenReturn(cartModelMock);

    final boolean result = testObj.processOrderModificationMessages(AUTHORIZATION);

    assertTrue(result);
    verify(worldpayOrderNotificationHandlerMock, never()).handleNotificationBusinessProcess(AUTHORIZATION, worldpayOrderModificationMock, orderModelMock, orderNotificationMessageMock);
    verify(worldpayOrderModificationMock, never()).setProcessed(Boolean.TRUE);
    verify(worldpayOrderModificationMock, never()).setDefective(any(Boolean.class));
}

Thank you for your support.

Regards.

There is no license attached to this extension. Which license applies? MIT? Apache Software Foundation? Or maybe it's not even open source, and there's a cost for using these extensions?

At minimum I would assume that any retailer using these extensions has to have a contract to use WorldPay and Hybris, but that doesn't speak to the licensing or commercials of these extensions? Are these extensions an add-on product that WorldPay charges to its Hybris customers?

We know that Merchant Defined Parameters (MDP) should be possible with the World Pay API:

https://beta.developer.worldpay.com/docs/wpg/hostedintegration/paymentpageintegration#merchant-defined-parameters

We know from our experience (and usage of a competing provider) that the usage of MDP is a common requirement to aid finance teams with their reporting.

Does the plugin support MDP? If not, where would it fit in the roadmap for the plugin?

Since this is a public github repository, what are the guidelines for contributing pull requests to this repository?

Are any contributions accepted? Or maybe none?

Hi, as Worldpay notified they are going to change the type PAYPAL-EXPRESS to PAYPAL-SSL. I just want to ask do you have any plans to fix it in this project?
Kind regards,
Mohsen

@rselimi ,
Would you mind adding release notes for the last release to "master"? We'd like to upgrade to the latest and greatest version of your plugin. We'd like to understand what goes in the plugin.

Hello Worldpay team, I am a backend engineer representing the Wilko project.

We've recently (Nov 16th) updated the worldpay plugin to 1905_7.0 version, and since then, we've been getting the following error:

Cannot invoke "org.springframework.http.ResponseEntity.getHeaders()" because "responseXML" is null, java.lang.NullPointerException in com.worldpay.service.http.impl.DefaultWorldpayConnector.processResponseXML(final ResponseEntity responseXML):111

It seems that, in some cases, the response from Worldpay request was getting passed as null into the processResponseXML() method. After some investigation, the root cause proved to be the use of the reactive API of RxJava on the following line

final Single<ResponseEntity<String>> response = sendOutboundXML(outboundPaymentService, merchantInfo, cookie);
response.subscribe(responseXML::set);
return processResponseXML(responseXML.get());

— the Single.subscribe() method is not blocking, and if the request takes a little bit longer than usual to return the response (for example it goes into the retry loop defined here), the responseXML.get() bit ends up being null, because the subscribe callback doesn't have a chance to set the response.

The logical question would be, why is this issue manifesting now more aggressively than before, since the above code hasn't been touched in the latest release? — the answer is the newly added delay. Adding a delay between the retry attempts, increased the odds of this issue manifesting itself more often than usual.

Here is a unit test, which you can add to DefaultWorldpayConnectorTest, to help reproduce this issue:

@Test
public void send_WhenTheResponseIsDelayedByRetries_ShouldSendThePaymentServiceTransformedInXML() throws Exception
{
    final var body = "body";
    final var cookie = "cookie";
    final var someXML = "someXML";
    final var inputStreamArgumentCaptor = ArgumentCaptor.forClass(InputStream.class);

    when(responseEntityMock.getHeaders()).thenReturn(httpHeadersMock);
    when(httpHeadersMock.get(HttpHeaders.SET_COOKIE)).thenReturn(List.of(cookie));
    when(responseEntityMock.getBody()).thenReturn(body);
    when(paymentServiceMarshallerMock.unmarshal(inputStreamArgumentCaptor.capture())).thenReturn(paymentServiceReplyMock);
    when(paymentServiceMarshallerMock.marshalAsFragment(paymentServiceRequestMock)).thenReturn(someXML);
    when(restTemplateMock.postForEntity(uriArgumentCaptor.capture(), httpEntityArgumentCaptor.capture(), eq(String.class)))
            .thenThrow(new ResourceAccessException(""))
            .thenThrow(new ResourceAccessException(""))
            .thenReturn(responseEntityMock);

    assertThat(testObj.send(paymentServiceRequestMock, merchantInfoMock, cookie))
            .extracting(ServiceReply::getPaymentService, ServiceReply::getCookie)
            .containsExactly(paymentServiceReplyMock, cookie);

    final var uri = uriArgumentCaptor.getValue();
    assertThat(uri.toString()).isEqualTo(ENDPOINT);

    final byte[] plainCreds = ("merchantCode" + ":" + "merchantPassword").getBytes(StandardCharsets.UTF_8);
    final var request = httpEntityArgumentCaptor.getValue();
    assertThat(request.getHeaders()).containsAllEntriesOf(Map.of(
            HttpHeaders.AUTHORIZATION, List.of("Basic " + new String(Base64.getEncoder().encode(plainCreds))),
            HttpHeaders.HOST, List.of(uri.getHost()),
            HttpHeaders.COOKIE, List.of(cookie)));
    assertThat(request.getBody()).startsWith(XML_HEADER).contains(someXML);
    assertThat(inputStreamArgumentCaptor.getValue()).hasSameContentAs(IOUtils.toInputStream(body, StandardCharsets.UTF_8));

    verify(restTemplateMock, times(3)).postForEntity(eq(URI.create(ENDPOINT)), anyObject(), eq(String.class));
}

Our current hotfix for this is to do

responseXML.set(response.toBlocking().value());

instead of

response.subscribe(responseXML::set);

however it would be nice to have this fixed upstream.

Hope this feedback was helpful to you.

P.S. something like RetryTemplate might be more fitting here instead of RxJava for the retry mechanism.