Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cash payment not working again #3879

Closed
Tracked by #32
Paul-Eraman-CoopCycle opened this issue Nov 18, 2023 · 15 comments
Closed
Tracked by #32

Cash payment not working again #3879

Paul-Eraman-CoopCycle opened this issue Nov 18, 2023 · 15 comments
Assignees
Labels
bug losing-money-bug A bug that makes me lose money

Comments

@Paul-Eraman-CoopCycle
Copy link
Contributor

Describe the bug
Clicking on the cash payment option and then clicking on "pay" refreshes the page but does not create an order.

To Reproduce
Steps to reproduce the behavior:

  1. Go to https://libelubike.coopcycle.org/es/forms/KMyGYdaO96XN
  2. Fill out formula, click next
  3. cllick on the cash payment icon, then pay
  4. See refresh without order creation

Expected behavior
an order should be created

Screenshots
veracruzcashpayment

@lucasferraro
Copy link
Contributor

Can not reproduce the bug. Orders FP and FO created using CASH as payment method.

Peek.19-11-2023.20-44.mp4

@Paul-Eraman-CoopCycle
Copy link
Contributor Author

We tried it with brave and it worked, but now it doesnt again :/

video_2023-11-22_00-28-57.mp4

@alexsegura
Copy link
Member

alexsegura commented Nov 24, 2023

I am able to reproduce it, and the form is invalid because of the following error:

The delivery date is expired

So it's not linked to the payment method, but with validation of the timeslot.
This explains why it works "sometimes".
As the timeslot is very large on Libelubike (9AM - 9PM), it happens a lot.

To reproduce it:

  • Create a timeslot 4PM - 6PM
  • Try ordering at 5PM

It has always been like this: if the slot has begun, it is considered invalid.
Changing this would impact a lot of things (like what choices are shown to users in food deliveries)

if ($value->getLower() < $now) {
$this->context
->buildViolation($constraint->shippedAtExpiredMessage)
->setCode(ShippingTimeRange::SHIPPED_AT_EXPIRED)
->addViolation();
return;
}


It happens in this form, but NOT on a delivery form using the same timeslot configuration, because the creation/validation of the order is not performed exactly the same way.

@lucasferraro
Copy link
Contributor

Thanks Mex, nice catch of the reason.

So, maybe the first step is to handle this kind of validations and show the errors in the screen?

if ($paymentForm->isSubmitted() && $paymentForm->isValid()) {
$payment = $order->getLastPayment(PaymentInterface::STATE_CART);
$data = [
'stripeToken' => $paymentForm->get('stripePayment')->get('stripeToken')->getData()
];
if ($paymentForm->has('paymentMethod')) {
$data['mercadopagoPaymentMethod'] = $paymentForm->get('paymentMethod')->getData();
}
if ($paymentForm->has('installments')) {
$data['mercadopagoInstallments'] = $paymentForm->get('installments')->getData();
}
if (null === $order->getDelivery()) {
$order->setDelivery($delivery);
}
$orderManager->checkout($order, $data);
$objectManager->flush();
if (PaymentInterface::STATE_FAILED === $payment->getState()) {
return $this->render('embed/delivery/summary.html.twig', [
'hashid' => $hashid,
'delivery' => $delivery,
'price' => $price,
'price_excluding_tax' => ($order->getTotal() - $order->getTaxTotal()),
'form' => $paymentForm->createView(),
'payment' => $payment,
'order' => $order,
'error' => $payment->getLastError(),
'submission_hashid' => $request->query->get('data'),
]);
}
$this->addFlash(
'embed_delivery',
$this->translator->trans('embed.delivery.confirm_message')
);
$hashids = new Hashids($this->getParameter('secret'), 8);
return $this->redirectToRoute('public_order', [
'hashid' => $hashids->encode($order->getId())
]);
}
}

Adding an else clause here and rendering same page

else {
    return $this->render('embed/delivery/summary.html.twig', [
        'hashid' => $hashid,
        'delivery' => $delivery,
        'price' => $price,
        'price_excluding_tax' => ($order->getTotal() - $order->getTaxTotal()),
        'form' => $paymentForm->createView(),
        'payment' => $order->getLastPayment(PaymentInterface::STATE_CART),
        'order' => $order,
        'submission_hashid' => $request->query->get('data'),
    ]);
}

Then, I don't know if we want to change the existing behaviour that is causing the error. At a first glance, I think it's a bit annoying cancel a delivery just because the timeslot has begun.

@Paul-Eraman-CoopCycle
Copy link
Contributor Author

I have spoken to carmena, for the moment i believe we can make a workaround to make the platform viable while we figure out this problem

@Paul-Eraman-CoopCycle
Copy link
Contributor Author

For the moment I have explained this to them, and now they are using 1 hour intervals. We should keep this in mind for when we re-attack pricing and time concepts on the platform for when we make the needs analysis

if we could make that an error instead of a random breaking issue, that would be a fix for the moment and I can close this issue

@lucasferraro
Copy link
Contributor

With the current version of the platform I'm not able to reproduce this issue anymore, I don't know if anything has changed and fixed it.

BTW, making a test in my local env (timeslot 14:30 to 17:30 and creating a delivery at 16:20) with an old version of the code I was able to reproduce it to see if we can send the error (show error message) detected in the server when we check if the timeslot is valid:

Peek.29-04-2024.16-27.mp4

The existing translation of the error may not be so clear for the user, but at least it shows an error message related to the error. @Paul-Eraman-CoopCycle Let me know if it's ok and I'll push the change.

But again, maybe something has been changed in the code and this error described above by mex has been fixed already.

@Paul-Eraman-CoopCycle
Copy link
Contributor Author

I think mex's thing fixed it but it was hard to be sure (who knows if i tested enough things) so i think with the potential fix and an error message i think we can call it good to go, and see if i can break it again in live or not

@Paul-Eraman-CoopCycle
Copy link
Contributor Author

Image

@Paul-Eraman-CoopCycle
Copy link
Contributor Author

We need to test its implementation in:

  • shops
  • formulas

@alexsegura
Copy link
Member

The initial error about expired timeslot seems to have been fixed here

@alexsegura
Copy link
Member

The error in this comment seems to be something else than the initial issue reported. The initial issue happened at the next step, when paying, and was showing no error message.

@Paul-Eraman-CoopCycle
Copy link
Contributor Author

this link in your second to last comment doesnt lead me anywhere

@Paul-Eraman-CoopCycle
Copy link
Contributor Author

honestly im also a bit confused about what is going on, maybe i needed to make a new issue
but the current complaint is that comment you have linked to in your last message where you cant make an order inside of a time slot range

can we fix that?

@Paul-Eraman-CoopCycle
Copy link
Contributor Author

was resolved doing something else! 🥳

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug losing-money-bug A bug that makes me lose money
Projects
None yet
Development

No branches or pull requests

3 participants