Re: Stripe.com payment integration module
The version 2.1.14 do not include create.php and therefore causes error. It is obvious when installed from scratch.
Anyway, the module do not show CC input fields in the step 3/3 of the Checkout conformation, but an order is confirmed and put among orders and sent by email. I tried also ver. 2.1.12 and behavior is the same?
Re: Stripe.com payment integration module
Hello all,
I am testing my shop upgraded from ZC v1.5.6c to v2.1.0, and installed the Stripe module, which I was unable to use previously in Japan under 1.5.6.c.
I noticed that the code does not include generic order total processing, and seems to explicitly be coded only to handle low order fees.
In my case, since I upgraded the gift wrap module to PHP8 standards, the processing of the added amount is missing.
However, there could be many other situations of requiring order total processing: in the paypalwpp code, the entire order total processing is called in the code.
So I will try that approach in Stripe as well.
I am confused though: if the order total modules update
Code:
order->info['total']
, why is this not available to the payment modules, and why do they need to repeat the order total processing in order to re-obtain the correct value for the total?
Previously, in 1.5.6c, I was using the v1.0.4 Square module (and paypalwpp), where I now see that there is also no calling of the order total processing either, so I may have missed that payment was possibly less than the required amount for orders that had additional order processing fees.
Re: Stripe.com payment integration module
I’d like to clarify the behavior regarding `order->info['total']`.
Unlike other payment modules (such as PayPal WPP or Square), this Stripe module initiates the API call to Stripe during the `checkout_confirmation` stage. At that point, the order total—including any low order fee or other order total components—needs to be fully calculated, since it’s already being transmitted to the Stripe server before the confirmation button is pressed.
This differs from other payment modules where the order total is recalculated *after* pressing the confirmation button. So if you're using the low order fee module (or any custom `order_total` module), but that amount is not reflected in `order->info['total']` by the time you reach `checkout_confirmation`, it will not be included in the amount sent to Stripe.
If you’re not using low order fees or other dynamic order total adjustments, then relying on `order->info['total']` at that stage may be fine. But to ensure consistency, the Stripe module assumes that all necessary order total processing is completed **before** the confirmation page is loaded.
Let me know if you'd like to go over integration strategies for your particular setup—I’d be happy to walk through adjustments or considerations.
As a side note, the problems found in the previous Stripe module (which relied on a POST submission method) have already been resolved. That said, reverting to that outdated architecture doesn’t seem necessary at this point.
Re: Stripe.com payment integration module
Hello @gozzandes
Many thanks for your explanation. I've been confusing myself trying to understand the logic of multiple payment modules and how order_total is use in various places, so I will need some time to reset my brain, read and digest your explanation, and thereby understand the code.
In the meantime, since $order->info['total'] at the time the stripe.php module was loaded was the plain product total only, I found that I could include the required order_total additions by requesting them in the pre_confirmation_check() function before the $amount_total is calculated.
PHP Code:
function pre_confirmation_check() {
// add $order_totals, $order_total_modules globals
global $order, $db, $stripeCustomerID, $user_id, $stripe_select, $order_totals, $order_total_modules;
/../
// debug - add any order_total additions for Stripe to get the correct amount
if (MODULE_ORDER_TOTAL_INSTALLED) {
$order_totals = $order_total_modules->process();
}
// end debug
if ( isset($_SESSION['opc_saved_order_total'])) {
$order_value = $_SESSION['opc_saved_order_total'];
}else{
if (MODULE_ORDER_TOTAL_LOWORDERFEE_LOW_ORDER_FEE == 'true' && MODULE_ORDER_TOTAL_LOWORDERFEE_ORDER_UNDER >= $order->info['total']) {
$order_value = $order->info['total'] + MODULE_ORDER_TOTAL_LOWORDERFEE_FEE ;
} else{
$order_value = $order->info['total'];
}
}
$amount_total=round($order_value * $order->info['currency_value'],$decimal_places)*$multiplied_by;
/../
I understand this is hack and I need to also change the code below with lowerorder fee.
Re: Stripe.com payment integration module
Addendum:
In the stripe.php module I saved the original total, and then recovered it, so as not to disturb the further flow.
PHP Code:
// debug - need to add any order_total additions for Stripe to get the correct amount
if (MODULE_ORDER_TOTAL_INSTALLED) {
// first retain original total
$origTotal = $order->info['total'];
$order_totals = $order_total_modules->process();
}
// not using OPC
//if ( isset($_SESSION['opc_saved_order_total'])) {
// $order_value = $_SESSION['opc_saved_order_total'];
// }else{
//
// if (MODULE_ORDER_TOTAL_LOWORDERFEE_LOW_ORDER_FEE == 'true' && MODULE_ORDER_TOTAL_LOWORDERFEE_ORDER_UNDER >= $order->info['total']) {
// $order_value = $order->info['total'] + MODULE_ORDER_TOTAL_LOWORDERFEE_FEE ;
// } else{
// $order_value = $order->info['total'];
// }
// }
$order_value = $order->info['total'];
$amount_total=round($order_value * $order->info['currency_value'],$decimal_places)*$multiplied_by;
// return total to its original
$order->info['total'] = $origTotal;
And then in class order_total.php I initialized the output so that it is not duplicated every time process() is called:
PHP Code:
public function process(): array
{
global $order;
/../
// start debug - zero out the output
$GLOBALS[$class]->output = [];
// end debug
$GLOBALS[$class]->process();
/../
Re: Stripe.com payment integration module
i am hesitant to weigh in on this topic. but here we go...
Quote:
Originally Posted by
gernot
Hello all,
I am testing my shop upgraded from ZC v1.5.6c to v2.1.0, and installed the Stripe module, which I was unable to use previously in Japan under 1.5.6.c.
I noticed that the code does not include generic order total processing, and seems to explicitly be coded only to handle low order fees.
In my case, since I upgraded the gift wrap module to PHP8 standards, the processing of the added amount is missing.
However, there could be many other situations of requiring order total processing: in the paypalwpp code, the entire order total processing is called in the code.
So I will try that approach in Stripe as well.
I am confused though: if the order total modules update
Code:
order->info['total']
, why is this not available to the payment modules, and why do they need to repeat the order total processing in order to re-obtain the correct value for the total?
Previously, in 1.5.6c, I was using the v1.0.4 Square module (and paypalwpp), where I now see that there is also no calling of the order total processing either, so I may have missed that payment was possibly less than the required amount for orders that had additional order processing fees.
unfortunately one really needs to examine the order object at the time of its use. it is easily manipulated by not following a best practices scenario. which any extra order_total object certainly can do.
in addition, OPC and standard 3 page checkout differ in when they call the order total process method.
you can review some of the discussions that i have had here and here.
Quote:
Originally Posted by
Gozzandes
I’d like to clarify the behavior regarding `order->info['total']`.
Unlike other payment modules (such as PayPal WPP or Square), this Stripe module initiates the API call to Stripe during the `checkout_confirmation` stage. At that point, the order total—including any low order fee or other order total components—needs to be fully calculated, since it’s already being transmitted to the Stripe server before the confirmation button is pressed.
This differs from other payment modules where the order total is recalculated *after* pressing the confirmation button. So if you're using the low order fee module (or any custom `order_total` module), but that amount is not reflected in `order->info['total']` by the time you reach `checkout_confirmation`, it will not be included in the amount sent to Stripe.
If you’re not using low order fees or other dynamic order total adjustments, then relying on `order->info['total']` at that stage may be fine. But to ensure consistency, the Stripe module assumes that all necessary order total processing is completed **before** the confirmation page is loaded.
Let me know if you'd like to go over integration strategies for your particular setup—I’d be happy to walk through adjustments or considerations.
As a side note, the problems found in the previous Stripe module (which relied on a POST submission method) have already been resolved. That said, reverting to that outdated architecture doesn’t seem necessary at this point.
gozzandes, i would suggest you stay on topic with regards to your payment module and base zen-cart. i have coded payment modules that require all order total modules to be calculated at the time of checkout confirmation; and i believe i do that in my square module. if, in fact, the base zen-cart is not given you the data you need at the time you need it to make your API call, then i would suggest a PR on the base ZC is in order.
hard coding your low fee or any other order total into your payment module is not what i would consider best practices; although i do see and appreciate all of the work that you have put into this module, payment modules are not easy.
again, i would review this closed PR; and specifically this comment in there.
one can get the data from all of the order total modules using:
PHP Code:
$calculatedTotal = $order_total_modules->pre_confirmation_check(true);
note that pre_confirmation_check method has evolved a slight bit over the last few releases. but using it is a much better solution than hard coding any order total modules OR calling the process method and manually saving the order->info total. the base code will do it all for you.
Re: Stripe.com payment integration module
Hello @carlwhat
Thank you for weighing in, much appreciated, the fog is slowly clearing!
I will read the related links you gave.
Thank you for pointing out one can get the order total figure using
PHP Code:
$calculatedTotal = $order_total_modules->pre_confirmation_check(true);
.
I note that inside this function process() is called (I effectively re-implemented the contents of the above in the Stripe module without realizing I could have just called pre_confirmation_check with true), so I think the initialization of output as an empty array is still worthwhile, as everytime process() is called (even inside pre_confirmation_check) it will add more copies of HTML to the output array (unless I am misunderstanding output, but I do not see any initialization of it).
That is the only core ZenCart change I felt I needed to make, I'll leave any changes to the Stripe module to align with ZC best practices as appropriate to @gozzandes although of course I am more than happy to help with testing and experimenting.
Re: Stripe.com payment integration module
When calling pre_confirmation_check(true), I think it would be beneficial to also save and restore the output array so that process() does not change it, in the same way as order->info['total'] is saved and restored.
Re: Stripe.com payment integration module
You're absolutely right—using `pre_confirmation_check(true)` is definitely the better approach. I'll make sure to implement this when I update the module.