Calling Developers!
We are reenergizing our code contribution process! Learn More

What are the Slack Archives?

It’s a history of our time together in the Slack Community! There’s a ton of knowledge in here, so feel free to search through the archives for a possible answer to your question.

Because this space is not active, you won’t be able to create a new post or comment here. If you have a question or want to start a discussion about something, head over to our categories and pick one to post in! You can always refer back to a post from Slack Archives if needed; just copy the link to use it as a reference..

Hi, i've got a maybe to detailled question, but maybe someone can help me here: Currently implementi

Options
michael.schmetter
michael.schmetter Posts: 119 🧑🏻‍🚀 - Cadet

Hi,
i've got a maybe to detailled question, but maybe someone can help me here:
Currently implementing an integration with a PSP.
The Happy Path is easy and works fine, but the error/abort case is where I am wondering, what I am missing.
As I understood and gathered from the integrations with Adyen/Computop/Crefopay... the order gets placed, the payment gets added to the sales order in the CheckoutDoSaveOrderInterface .
The actual call to the PSP to get the redirect URL for Paypal or Klarna for example is being done in a HookPlugin CheckoutPostSaveInterface .
When the customer then cancels this payment and gets redirected to the shop, I can "reset" the customer session by setting for example:

$quoteTransfer
  ->setIsOrderPlacedSuccessfully(null)
  ->setOrderReference(null)
  ->setPayment(null);

When doing that the customer is treated correctly, but in the back the order was still placed and is now in payment pending state (Visible in BO and the customers order history)
Some solution could be setting a dedicated status for such orders (at failure notification or periodically), that gets filtered out for the endcustomer.
I could not find anything like that in the ootb integrations, am I missing something here or is this actually "project work"?
Thanks in advance!

Comments

  • UK7KBE2JW
    UK7KBE2JW Posts: 463 🧑🏻‍🚀 - Cadet
    Options

    Its the same problem with payone. When the customer reachs the external checkout like paypal or the 3d secure and cancels, the order ist already persisted and waits for the response. We added a timeout for to days in the oms so that the order get moved to invalid state

  • Alberto Reyer
    Alberto Reyer Lead Spryker Solution Architect / Technical Director Posts: 690 🪐 - Explorer
    Options

    Beside the technical background that the order needs to be stored before the payment might fail to be able to update the order in the success case, there is also a business perspective to take into account.

    Handling of failed payments depends a lot on your company processes.
    For one shop it might be enough to not fulfill orders with failed payments and do not care about them anymore.
    Another shop might want to catch up on those failed payments, either by reaching out to the customer and offer them a different payment method (needs implementation) or by falling back to an alternative payment method that is always available (often invoice).
    The second solution also heavily depends on your business cases. Do you sell cheap products or have other reasons, where a non collected payment might be not that bad, or do you sell luxury products, have a small margin anyway or a high fraud rate already? Depending on the case you might want to handle failed payments completely different. So IMO it's good that most payment implementations do not have a default and force you in the project to calculate how risky is a failed payment, what will happen in such cases?

    For your KPI's you also want to store and analyze those failed payment.
    Maybe you want to know what payment methods have the highest failure rate. Or how likely is it that my customer will retry after a failed payment attempt with a different payment methods.
    Or find out why do customers abort the payment?

    In a startup I've worked for we could learn from the failed payments that redirecting to the payment provider was too long, which we wouldn't have seen in the first place when we would not have so many failed payments.
    (Solution was to show a page before the redirect with a message to be a little bit patient and that it might take up to 3 minutes, which significantly lowered the aborted/failed payments).

  • michael.schmetter
    michael.schmetter Posts: 119 🧑🏻‍🚀 - Cadet
    Options

    Thank you for the responses. Great to hear, that I did not miss anything.
    @UK7KBE2JW And you hid those orders in the order history of the customer?

  • UK7KBE2JW
    UK7KBE2JW Posts: 463 🧑🏻‍🚀 - Cadet
    Options

    This will be a thing tbd. Atm we have no customer account where the customer can this order. In the back office the order is connected to the customer. But when the order was cancelt on psp side, its still in the customer session and the order ref will be removed so the customer can proceed a new checkout with same or other payment method. After the 2 day timeout the order will be listed in our reporting

  • michael.schmetter
    michael.schmetter Posts: 119 🧑🏻‍🚀 - Cadet
    Options

    Great!
    And with "our reporting" you mean something external?

  • UK7KBE2JW
    UK7KBE2JW Posts: 463 🧑🏻‍🚀 - Cadet
    Options

    Grafana