Introduce an event to modify the skipped adjustment types during order request generation

Created on 15 November 2024, 7 days ago

We are experiencing a problem with PayPal payments, as the API returns an UNPROCESSABLE_ENTITY error (CANNOT_BE_NEGATIVE) with certain carts. In this project, we have defined a custom adjustment type, which reduces the order total, hence is negative - which PayPal API doesn't allow.

The CheckoutSdk class is already skipping certain adjustment types, such as tax, shipping, promotion and giftcards. And yes, there's already an CheckoutOrderRequestEvent which allows us to modify the request before it is sent. However, walking through the items and identifying the problematic ones is a bit cumbersome and not the cleanest solution imho.

Therefore I'm suggesting introducing a new event, that allows us directly to add/remove these skipped adjustment types

Feature request
Status

Active

Version

1.0

Component

PayPal Checkout

Created by

🇦🇹Austria agoradesign

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @agoradesign
  • Pipeline finished with Failed
    7 days ago
    Total: 166s
    #339675
  • 🇮🇱Israel jsacksick

    hm... this event is reallllly specific... I'd be more in favor of introducing a setting for that (maybe at the gateway level?) Problem is, this method doesn't have access to the gateway... Could be just a setting that we fetch via Settings::get(), we'd just need to document it, but similar to how we have an event that you'd need to know about...

  • Pipeline finished with Failed
    7 days ago
    Total: 148s
    #339691
  • 🇦🇹Austria agoradesign

    ok, I see, we also need to fix the $breakdown.. but anyway, this can be done inside CheckoutOrderRequestEvent as well, so having this extra event would still be valuable imho

  • Pipeline finished with Failed
    4 days ago
    Total: 147s
    #341919
  • 🇦🇹Austria agoradesign

    @jsacksick I haven't really recognized your comment on friday. just saw it :D

    hmm well, yes it is specific, but I believe we should be open to custom adjustment types, allowing them to have a solid way to integrate themselves. why should it harm to use events?

    We have actually 2 different places inside prepareOrderRequest(), where we deal with an hardcoded opinionated list of adjustment types (skip, discount). my latest commit considers both (I have added in total 2 events, re-using the same event class)

Production build 0.71.5 2024