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?

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 ```
order->info['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.

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.

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.

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.

Addendum:
In the stripe.php module I saved the original total, and then recovered it, so as not to disturb the further flow.

  // 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:

    public function process(): array
    {
        global $order;
/../
                // start debug - zero out the output
                $GLOBALS[$class]->output = [];
               // end debug

                $GLOBALS[$class]->process();
/../

i am hesitant to weigh in on this topic. but here we go...

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 ```
order->info['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](https://github.com/zencart/zencart/pull/7041) and [here](https://github.com/lat9/one_page_checkout/issues/433).


> **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;](https://github.com/zencart/zencart/pull/7041) and specifically [this comment](https://github.com/zencart/zencart/pull/7041#issuecomment-2762559655) in there.  

one can get the data from all of the order total modules using:

```php
$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.

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

$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.

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.

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.

Hello,
Can someone please give some guidance.
Is there any way to set the locale locale=ja somewhere in the code?
Thanks

Ignore the above, tested it with Japanese OS, it works perfectly.
I wonder why they need Country Japan at the bottom of the form though... seems unnecessary

using ZC 2.1.0 with OPC. PayPal payments accepted through Stripe.
Payment attempts were failing with the following error:

You must provide a `return_url` when confirming a PaymentIntent with the payment method type paypal.

Had to modify includes/modules/payment/stripepay/create.php
from

$jason_FormLayout = json_encode(MODULE_PAYMENT_STRIPE_LAYOUT);
$confirmationURL = '"' . HTTPS_SERVER . DIR_WS_HTTPS_CATALOG . 'index.php?main_page=checkout_confirmation"';

to

$jason_FormLayout = json_encode(strtolower(MODULE_PAYMENT_STRIPE_LAYOUT));
$confirmationURL = HTTPS_SERVER . DIR_WS_HTTPS_CATALOG . 'index.php?main_page=checkout_confirmation';

First line change was related to another error being thrown... :smile:

This plugin says it only works for US and Canadian bank account holders - but that was a statement made in 2012.

Is this still the case - a few posts back I see someone based in Japan is evidently using it?

Stripe now claims to be global.

Apparently this module relies on the user returning to the website to note the payment was a success and there is no webhook file which can result in an order being placed and paid for but not being recorded??

Stripe library has a "webhook.php" which apparently isn't the file i should point too in stripes dashboard under webhooks settings?

I have had a number of these unrecorded orders and always put it down to checkout rush but on another site with the same module and no checkout rush issues i found a revolut payment was taken from my customer but the system treated it like they had not paid and their basket remained filled with the items.

Do I set the url to '/checkout_success' or does this module require a "/stripe_webhook.php" as chatgpt suggests? (provided below but... the code it provided for this looks like it has placeholders and a few details wrong.. made up functions ect lol)

<?php
// /stripe_webhook.php
// Minimal Stripe webhook for Zen Cart

chdir(__DIR__);
require 'includes/application_top.php'; // boot Zen Cart (DB, constants)
require 'includes/modules/payment/stripepay/vendor/autoload.php';

$endpointSecret = getenv('STRIPE_WEBHOOK_SECRET') ?: 'whsec_PUT_YOUR_SECRET_HERE';

// Simple health-check for you
if ($_SERVER['REQUEST_METHOD'] === 'GET') {
  header('Content-Type: text/plain'); echo "ok\n"; exit;
}

$payload = @file_get_contents('php://input');
$sig     = $_SERVER['HTTP_STRIPE_SIGNATURE'] ?? '';

try {
  $event = \Stripe\Webhook::constructEvent($payload, $sig, $endpointSecret);
} catch (\UnexpectedValueException $e) {
  http_response_code(400); echo 'Invalid payload'; exit;
} catch (\Stripe\Exception\SignatureVerificationException $e) {
  http_response_code(400); echo 'Invalid signature'; exit;
}

$type   = $event['type'] ?? '';
$object = $event['data']['object'] ?? [];

function zc_log($m){ error_log('[stripewh] '.$m."\n", 3, __DIR__.'/logs/stripe_webhook.log'); }

switch ($type) {
  case 'payment_intent.succeeded':
    $pi   = $object;
    $txn  = $pi['id'] ?? '';
    $amt  = isset($pi['amount_received']) ? ($pi['amount_received']/100.0) : 0;
    $cur  = strtoupper($pi['currency'] ?? '');
    $oid  = $pi['metadata']['zc_order_id'] ?? $pi['metadata']['order_id'] ?? null;
    if ($oid) {
      $orders_id = (int)$oid;
      $rs = $db->Execute("SELECT orders_status FROM " . TABLE_ORDERS . " WHERE orders_id=$orders_id LIMIT 1");
      if (!$rs->EOF) {
        $paid_status_id = defined('MODULE_PAYMENT_STRIPEPAY_ORDER_STATUS_PAID_ID')
          ? (int)MODULE_PAYMENT_STRIPEPAY_ORDER_STATUS_PAID_ID : 2; // adjust to your "Paid" status
        if ((int)$rs->fields['orders_status'] !== $paid_status_id) {
          $db->Execute("UPDATE " . TABLE_ORDERS . " SET orders_status=$paid_status_id, last_modified=NOW() WHERE orders_id=$orders_id");
          $db->Execute("INSERT INTO " . TABLE_ORDERS_STATUS_HISTORY . " (orders_id, orders_status_id, date_added, customer_notified, comments)
                        VALUES ($orders_id, $paid_status_id, NOW(), 0, 'Stripe PI ".$txn."  ".$amt." ".$cur." (webhook)')");
        }
      } else {
        zc_log("order $orders_id not found for txn $txn");
      }
    } else {
      zc_log("no order_id metadata for txn $txn");
    }
    break;

  case 'checkout.session.completed':
    $cs  = $object;
    $oid = $cs['metadata']['zc_order_id'] ?? null;
    $txn = is_array($cs['payment_intent'] ?? null) ? ($cs['payment_intent']['id'] ?? '') : ($cs['payment_intent'] ?? '');
    if ($oid) {
      $orders_id = (int)$oid;
      $paid_status_id = defined('MODULE_PAYMENT_STRIPEPAY_ORDER_STATUS_PAID_ID')
        ? (int)MODULE_PAYMENT_STRIPEPAY_ORDER_STATUS_PAID_ID : 2;
      $db->Execute("UPDATE " . TABLE_ORDERS . " SET orders_status=$paid_status_id, last_modified=NOW() WHERE orders_id=$orders_id");
      $db->Execute("INSERT INTO " . TABLE_ORDERS_STATUS_HISTORY . " (orders_id, orders_status_id, date_added, customer_notified, comments)
                    VALUES ($orders_id, $paid_status_id, NOW(), 0, 'Stripe Checkout ".$txn." (webhook)')");
    } else {
      zc_log("checkout.session.completed without order id");
    }
    break;

  default:
    // ignore others
}

http_response_code(200);
echo 'ok';

flappingfish:

Apparently this module relies on the user returning to the website to note the payment was a success and there is no webhook file which can result in an order being placed and paid for but not being recorded??

Stripe library has a "webhook.php" which apparently isn't the file i should point too in stripes dashboard under webhooks settings?

I have had a number of these unrecorded orders and always put it down to checkout rush but on another site with the same module and no checkout rush issues i found a revolut payment was taken from my customer but the system treated it like they had not paid and their basket remained filled with the items.

Do I set the url to '/checkout_success' or does this module require a "/stripe_webhook.php" as chatgpt suggests? (provided below but... the code it provided for this looks like it has placeholders and a few details wrong.. made up functions ect lol)

I've been looking into this as well, and my conclusion is that it's more complicated than you might think.

Basically the idea is that you can use a webhook to catch successful payments when the customer for some reason doesn't return to the confirmation page, and let the server handle the order.

Setting the webhook url to the success page won't do the trick because you want the payment to be processed first. Setting it to the confirmation page won't work either, because there's no customer, so there's no session, and nothing will be processed.

In theory you could set it to the confirmation page (or directly to main_page=checkout_process) with the session id in the url to restore the session, and thus make the necessary information available to process the order. However, there's no customer logged in, so stripe will be thrown out. You might circumvent that, and write an alternative checkout_process module, but I think you must really know what you are doing to keep that secure.

There could be another reason for these unrecorded orders though. You might want to make sure that the process for return based payment methods is working correctly, because for me it wasn't.

I encountered three problems:

1. As already pointed out by bahlir, the $confirmationURL needs to be changed or you will get an error

2. If you require conditions to be checked, the conditions will not be posted when the customer returns to the page, and will be redirected to the payment page,

I fixed that with a check in the header.php

$stripeRedirect = false;

if (isset($_GET['redirect_status'])) $stripeRedirect = true; 

if (DISPLAY_CONDITIONS_ON_CHECKOUT == 'true' && !$stripeRedirect) {
  if (!isset($_POST['conditions']) || ($_POST['conditions'] != '1')) {
    $messageStack->add_session('checkout_payment', ERROR_CONDITIONS_NOT_ACCEPTED, 'error');
  }
}

3. When the customer is redirected to the confirmation page the javascript variables set by create.php have gone out of scope. Without a PublishableKey the script will return an error and nothing happens. I was able to fix that by redeclaring this variable in the jscript_stripe.php when $stripeRedirect is true, but there is probably a more elegant solution, if you know more about Javascript than I do.

I'm testing the Stripe.com payment integration module using ZC 2.1.0 without OPC, but it's possible that you have the same problem in your setup, and that might be another reason why orders have been paid for but are not processed.

You need to choose a redirect based payment method to test this. I'm now testing IDEAL, a payment method that is popular in the Netherlands.

Yes that statement is donkeys years old, Stripe is pretty much global and defo works in Japan :)

zc2.10
bootstrap
php8.3

So far unable to get an order to generate in the cart. Everything else appears to be working, no errors on screen, credit card fields appear correctly, click the button and get the spinner, transaction is generated in the Stripe dashboard, and money taken from my account. it is just the order generation in the cart that never happens.

sounds like the same issue i "occasionally" get. customers will ring me and inform me they checked out, got charged and never got an order confirmation. ZXPOS is quite useful for these instances, simply log in as customer and push basket through as instore card payment once strip payment confirmed. possible you have not updated the module with the correct files for 2.1 there is a different file set i believe. I think your issue resides in having the wrong version of stripe_create.php (I think that is the correct filename) If you have the wrong file i think your sql queries will be associated to older database namings, the mismatch in names results in a silent failure caused by bad sql query i think?

I am using the latest here: https://www.zen-cart.com/downloads.php?do=file&id=1548