Closed i-just closed 5 months ago
As per our discussions, I went back to accepting false
and leaving the null
behaviour as it was when generating checkout URLs.
This means that if you don’t pass anything as a $customer
parameter, the default null
value will be used, and the method will continue to attempt to get the currently logged-in user. However, if you pass false
, the checkout URL will be anonymous (even if a user is currently logged in).
I also unified how the checkout is generated in all 3 cases: via controller action (stripe/checkout
), twig function (stripeCheckoutUrl()
) and price element method (price.getCheckoutUrl()
).
Description
This PR addresses a few bugs and slightly changes the behaviour of the
src\services\Checkout->getCheckoutUrl()
method to allow truly anonymous checkout.customer_email
to null, causing a Stripe API errorsrc\services\Checkout->getCheckoutUrl()
now acceptsfalse
as the$user
parameter too. Ifnull
is passed (or the parameter is not explicitly used, in which case it’ll default tonull
), the method will continue to attempt to get the currently logged-in user. Iffalse
is passed, no such attempt will be made, the checkout URL will be anonymous, and the customer will have to fill out their email address on Stripe’s checkout page. (README adjusted accordingly.)src\elements\Price->getCheckoutUrl()
now accepts parameters ($customer
,$successUrl
,$cancelUrl
,$params
), all defaulting tonull
, and no longer assumes that the current user should always be used when generating the checkout URL.Related issues
n/a