Stripe.com payment integration module

On activating the Stripe account (code to phone), one is presented with a thank you page, saying the account is now live, and a list of things to double check.

1. Use your live key (for API calls)
2. Use your live publishable key with Stripe.js
3. Enable HTTPS on your site
4. Add a Specified Commercial Transactions Act page

This last one was a new one of me. Here the details:

Japanese law requires that all businesses accepting payments online provide specific information about their business by linking to a Specified Commercial Transactions Act page (特定商取引法に基づく表記) on their site.
Stripe kindly provides information on how to comply, here the links for English and Japanese:

• English: https://support.stripe.com/questions/en-specified-commercial-transactions-act
• Japanese: https://support.stripe.com/questions/jp-specified-commercial-transactions-act

I could not actually find such pages on several shop sites I look at regularly. Wonder if anyone here knows more details about this. I'm not sure if I need to make a distinct an obvious page link (as suggested by Stripe), such as for Privacy Policy, Terms and Conditions, and so forth, or whether the necessary information can be included as part of an existing page.

This seems to be specific to Japan; however, if there are similar regulations in some other countries, would be nice to hear any input.

OK, I have decided to put some time into attempting to debug the Stripe module. So first, attempt to correct the issue with stripe_object:

desc stripe_data;
+----------------------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+----------------------------+--------------+------+-----+---------+----------------+
| stripe_object | varchar(64) | NO | | NULL | |After running
ALTER TABLE stripe_data
CHANGE stripe_object stripe_object varchar(64) NULL DEFAULT '';the definition changes to
desc stripe_data;
+----------------------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+----------------------------+--------------+------+-----+---------+----------------+
| stripe_object | varchar(64) | YES | | | |Unfortunately, when I try a Stripe checkout, after entering the sandbox data I get at
https://***/shop/index.php?main_page=checkout_process
the following display (no other output)
WARNING: An Error occurred, please refresh the page and try again.and on refreshing the page, the warning
Must provide source or customer.displays under "Step 3 of 3 - Order Confirmation".

The debug log now shows a different error though, which is a welcome change:

[31-Jul-2019 00:13:32 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Charge instance: customer
[31-Jul-2019 00:13:32 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Charge instance: disputed
[31-Jul-2019 00:13:32 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Charge instance: fee
[31-Jul-2019 00:13:32 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Charge instance: invoice
[31-Jul-2019 00:13:32 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Object instance: address_city
[31-Jul-2019 00:13:32 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Object instance: address_country
[31-Jul-2019 00:13:32 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Object instance: address_line1
[31-Jul-2019 00:13:32 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Object instance: address_line1_check
[31-Jul-2019 00:13:32 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Object instance: address_line2
[31-Jul-2019 00:13:32 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Object instance: address_zip
[31-Jul-2019 00:13:32 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Object instance: address_zip_check
[31-Jul-2019 00:13:32 Asia/Tokyo] Request URI: /shop/index.php?main_page=checkout_process, IP address: 192.168.0.3
#1 trigger_error() called at [//shop/includes/classes/db/mysql/query_factory.php:171]
#2 queryFactory->show_error() called at [//shop/includes/classes/db/mysql/query_factory.php:143]
#3 queryFactory->set_error() called at [//shop/includes/classes/db/mysql/query_factory.php:270]
#4 queryFactory->Execute() called at [//shop/includes/functions/functions_general.php:952]
#5 zen_db_perform() called at [//shop/includes/modules/payment/stripepay.php:495]
#6 stripepay->after_process() called at [//shop/includes/classes/payment.php:254]
#7 payment->after_process() called at [//shop/includes/modules/pages/checkout_process/header_php.php:17]
#8 require(//shop/includes/modules/pages/checkout_process/header_php.php) called at [//shop/index.php:36]
--> PHP Fatal error: 1406:Data too long for column 'stripe_charge_id' at row 1 :: INSERT INTO stripe_data (orders_id, stripe_charge_id, customers_id, stripe_amount, stripe_amount_refunded, stripe_currency, stripe_customer, stripe_description, stripe_disputed, stripe_fee, stripe_invoice, stripe_paid, stripe_address_city, stripe_address_country, stripe_address_line1, stripe_address_line1_check, stripe_address_line2, stripe_address_zip, stripe_address_zip_check, stripe_country, stripe_fingerprint, stripe_cvc_check, stripe_name, stripe_last4, stripe_exp_month, stripe_exp_year, stripe_type) VALUES ('36', 'ch_1F1x15IvuX80g3UFlLCPZ6ka', '2', '58290', '0', 'JPY', '', 'user AT gmail.com', '', '', '', '1', '', '', '', '', '', '', '', 'US', 'lHfW1lpMAnH1N1Ea', 'pass', 'USER NAME', '4242', '1', '2023', 'Visa') ==> (as called by) //shop/includes/functions/functions_general.php on line 952 <== in /***/shop/includes/classes/db/mysql/query_factory.php on line 171.I have replaced the actual email address and user name with "user AT gmail.com" and "USER NAME" in the error log contents.
The field stripe_charge_id is being set to ch_1F1x15IvuX80g3UFlLCPZ6ka, but in the stripe_data table is defined as varchar(25)

desc stripe_data;
+----------------------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+----------------------------+--------------+------+-----+---------+----------------+
| stripe_charge_id | varchar(25) | NO | | NULL | |Clearly, the value to be set is 27 chars long. Now I guess I need to check docs to see what the max value should be.
As a test, if I altered the field to be 27 varchars,
ALTER TABLE stripe_data CHANGE stripe_charge_id stripe_charge_id varchar(27) NOT NULL;
so that definition becomes:
desc stripe_data;
+----------------------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+----------------------------+--------------+------+-----+---------+----------------+
| stripe_charge_id | varchar(27) | NO | | NULL | |and tried checkout again.

An error still occurs, and debug log shows yet a different error. So some progress here.

As it is late, I will defer this, but it looks like the fee value is not being given correctly for the module's liking.

[31-Jul-2019 00:30:23 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Charge instance: customer
[31-Jul-2019 00:30:23 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Charge instance: disputed
[31-Jul-2019 00:30:23 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Charge instance: fee
[31-Jul-2019 00:30:23 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Charge instance: invoice
[31-Jul-2019 00:30:23 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Object instance: address_city
[31-Jul-2019 00:30:23 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Object instance: address_country
[31-Jul-2019 00:30:23 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Object instance: address_line1
[31-Jul-2019 00:30:23 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Object instance: address_line1_check
[31-Jul-2019 00:30:23 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Object instance: address_line2
[31-Jul-2019 00:30:23 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Object instance: address_zip
[31-Jul-2019 00:30:23 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Object instance: address_zip_check
[31-Jul-2019 00:30:23 Asia/Tokyo] Request URI: /shop/index.php?main_page=checkout_process, IP address: 192.168.0.3
#1 trigger_error() called at [//shop/includes/classes/db/mysql/query_factory.php:171]
#2 queryFactory->show_error() called at [//shop/includes/classes/db/mysql/query_factory.php:143]
#3 queryFactory->set_error() called at [//shop/includes/classes/db/mysql/query_factory.php:270]
#4 queryFactory->Execute() called at [//shop/includes/functions/functions_general.php:952]
#5 zen_db_perform() called at [//shop/includes/modules/payment/stripepay.php:495]
#6 stripepay->after_process() called at [//shop/includes/classes/payment.php:254]
#7 payment->after_process() called at [//shop/includes/modules/pages/checkout_process/header_php.php:17]
#8 require(//shop/includes/modules/pages/checkout_process/header_php.php) called at [//shop/index.php:36]
--> PHP Fatal error: 1366:Incorrect integer value: '' for column zencartshop.stripe_data.stripe_fee at row 1 :: INSERT INTO stripe_data (orders_id, stripe_charge_id, customers_id, stripe_amount, stripe_amount_refunded, stripe_currency, stripe_customer, stripe_description, stripe_disputed, stripe_fee, stripe_invoice, stripe_paid, stripe_address_city, stripe_address_country, stripe_address_line1, stripe_address_line1_check, stripe_address_line2, stripe_address_zip, stripe_address_zip_check, stripe_country, stripe_fingerprint, stripe_cvc_check, stripe_name, stripe_last4, stripe_exp_month, stripe_exp_year, stripe_type) VALUES ('37', 'ch_1F1xHOIvuX80g3UF1seaLy6J', '2', '58290', '0', 'JPY', '', 'user AT gmail.com', '', '', '', '1', '', '', '', '', '', '', '', 'US', 'lHfW1lpMAnH1N1Ea', 'pass', 'USER NAME', '4242', '1', '2020', 'Visa') ==> (as called by) //shop/includes/functions/functions_general.php on line 952 <== in /***/shop/includes/classes/db/mysql/query_factory.php on line 171.In sandbox no fee is taken, so the fact that the fee is not there is not a big surprise, but should it be an integer 0, or should the code accept an empty string?

I think that in the above, all these errors are generated by the Zen Cart module itself, not an error being reported by Stripe.

To be continued the following day.

One separate issue: stripe_country seems to be set to US. I expected it to be Japan, but I guess this value is coming from Stripe and is related to the sandbox credit card information being used. In includes/modules/payment/stripepay.php we have:

'stripe_country' => zen_db_prepare_input($charge->source->country),
I hope I am right in assuming this means the value I see is coming from Stripe's sandbox client.

For reference, stripe_fee is defined as non-null:

desc stripe_data;
+----------------------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+----------------------------+--------------+------+-----+---------+----------------+
| stripe_fee | int(11) | NO | | NULL | |So that means, in strict mode, and empty string will not be accepted.
Tomorrow I will test to see if I alter the fee to accept null, whether it then passes the previous data successfully.
However, I'd like to understand if that change is the correct way to handle such an issue.
It seems there are a few fields in the stripe_data table that would at first glance require non null, but are defined as accepting null entries.
So confused.

Reference:

desc stripe_data;
+----------------------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+----------------------------+--------------+------+-----+---------+----------------+
| stripe_id | int(11) | NO | PRI | NULL | auto_increment |
| orders_id | int(11) | NO | | NULL | |
| customers_id | int(11) | NO | | NULL | |
| stripe_charge_id | varchar(27) | NO | | NULL | | <- changed by me from original in module
| stripe_amount | int(25) | NO | | NULL | |
| stripe_amount_refunded | int(25) | YES | | NULL | |
| stripe_currency | varchar(6) | NO | | NULL | |
| stripe_customer | varchar(64) | YES | | NULL | |
| stripe_description | varchar(255) | YES | | NULL | |
| stripe_disputed | varchar(64) | NO | | NULL | |
| stripe_fee | int(11) | NO | | NULL | |
| stripe_invoice | varchar(64) | YES | | NULL | |
| stripe_object | varchar(64) | YES | | | | <- changed by me from original in module
| stripe_paid | int(11) | NO | | NULL | |
| stripe_address_city | varchar(255) | NO | | NULL | |
| stripe_address_country | varchar(255) | NO | | NULL | |
| stripe_address_line1 | varchar(255) | NO | | NULL | |
| stripe_address_line1_check | varchar(64) | YES | | NULL | |
| stripe_address_line2 | varchar(255) | YES | | NULL | |
| stripe_address_zip | varchar(255) | YES | | NULL | |
| stripe_address_zip_check | varchar(64) | YES | | NULL | |
| stripe_country | varchar(64) | NO | | NULL | |
| stripe_fingerprint | varchar(64) | NO | | NULL | |
| stripe_cvc_check | varchar(64) | YES | | NULL | |
| stripe_name | varchar(64) | NO | | NULL | |
| stripe_last4 | int(4) | NO | | NULL | |
| stripe_exp_month | int(2) | NO | | NULL | |
| stripe_exp_year | int(4) | NO | | NULL | |
| stripe_type | varchar(64) | NO | | NULL | |
+----------------------------+--------------+------+-----+---------+----------------+
29 rows in set (0.001 sec)

Continuation...
I changed the stripe_fee field in the stripe_data table to accept NULL, as follows:

+----------------------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+----------------------------+--------------+------+-----+---------+----------------+
| stripe_fee | int(11) | NO | | NULL | |

ALTER TABLE stripe_data CHANGE stripe_fee stripe_fee int(11) NULL default NULL;

+----------------------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+----------------------------+--------------+------+-----+---------+----------------+
| stripe_fee | int(11) | YES | | NULL | |However, I still get the same error when processing a sandbox payment. So an empty string value is apparently simply not acceptable. Stumped for now, will try to initialize the stripe_fee to 0 and see what happens.

After a bit of Googling, it seems my plan to allow NULL is mistaken. Since the default setting in MySQL/MariaDB is strict mode, empty values will not be permitted in integer fields, and to enter NULL would require a specific statement.
So it looks like I will need to cast empty string to integer 0 in PHP.

My conclusion is the between 2012, when the module was written (and obviously has worked well) many changes in MySQL have taken place, the most critical one being the application of strict mode, and also some changes in Stripe's API and fields.

I'll post again when I have figured out how to cast empty string to integer.

I note that I have no idea at this stage whether Stripe returns non-integer (fractional) values for some fields that are currently declared as integers. We shall see...

I hacked the stripe_fee field as follows in stripepay.php:

function after_process()
    {
        global $charge, $insert_id,  $db;
        //let's update the stripe_id table
        // let's see if we can change $charge->fee
        if (empty($charge->fee)) {
            $charge->fee = 0;
        }
/../
```That did manage to avoid the previous error, and instead, we get the next one.
Here the debug log:
> #1  trigger_error() called at [/***/shop/includes/classes/db/mysql/query_factory.php:171]
> #2  queryFactory->show_error() called at [/***/shop/includes/classes/db/mysql/query_factory.php:143]
> #3  queryFactory->set_error() called at [/***/shop/includes/classes/db/mysql/query_factory.php:270]
> #4  queryFactory->Execute() called at [/***/shop/includes/modules/payment/stripepay.php:509]
> #5  stripepay->after_process() called at [/***/shop/includes/classes/payment.php:254]
> #6  payment->after_process() called at [/***/shop/includes/modules/pages/checkout_process/header_php.php:17]
> #7  require(/***/shop/includes/modules/pages/checkout_process/header_php.php) called at [/***/shop/index.php:36]
> --> PHP Fatal error: 1406:Data too long for column 'cc_expires' at row 1 :: update orders set
>                                cc_type = '',
>                                cc_owner='USER NAME',
>                                cc_expires='1/2020',
>                                cc_number='XXXX-XXXX-XXXX-4242'
>                                     where
>                                 orders_id = '39'  ==> (as called by) /***/shop/includes/modules/payment/stripepay.php on line 509 <== in /***/shop/includes/classes/db/mysql/query_factory.php on line 171.I changed the actual user name to "USER NAME" above.
So it looks like it is going to be a long slog here, solving the definition of many fields used in the module.

*cc_expires* is a field in the table orders, and is defined as varchar(4), which clearly is incompatible with this module's attempt to set it to a format of "[M]M/YYYY".

Surely there is no way this module can work with Zen Cart if that is really the case? Maybe *cc_expires* used to be defined like this in older versions os Zen Cart?
I guess the way forward for now is to redefine, in the module, how *cc_expires* is created, to make it into the format ""MMYY", presumably. Mmm, substring from the year, and padding for the month as needed. Darn, lots of examples in the other payment modules, will have to hash up something there, no more time tonight though.

I can see a new working version at the end of this road, but I really wonder what other users have done to keep the module working on their newer Zen Cart systems.

Well, that was not that hard. Changed the code for cc_expires from

cc_expires='" . zen_db_prepare_input($charge->source->exp_month) . "/" . zen_db_prepare_input($charge->source->exp_year) . "',
```to
```php
cc_expires='" . zen_db_prepare_input(str_pad($charge->source->exp_month,2,'0',STR_PAD_LEFT)) .                                  zen_db_prepare_input(substr($charge->source->exp_year,-2)) . "',

and the order passed!!! Success, albeit with no doubt horrible code.

There are still warnings in the log:

[01-Aug-2019 00:42:46 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Charge instance: customer
[01-Aug-2019 00:42:46 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Charge instance: disputed
[01-Aug-2019 00:42:46 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Charge instance: invoice
[01-Aug-2019 00:42:46 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Object instance: address_city
[01-Aug-2019 00:42:46 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Object instance: address_country
[01-Aug-2019 00:42:46 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Object instance: address_line1
[01-Aug-2019 00:42:46 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Object instance: address_line1_check
[01-Aug-2019 00:42:46 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Object instance: address_line2
[01-Aug-2019 00:42:46 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Object instance: address_zip
[01-Aug-2019 00:42:46 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Object instance: address_zip_check
[01-Aug-2019 00:42:46 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Object instance: typeProbably since stripe_object is no longer used and the code needs to be cleaned up for that.

I do note though that address verification is an option (AVS check), and I have turned it off. Not sure if that is related. I will do another transaction with AVS check turned on and compare.

Note I also have turned off the option to create a Stripe customer object.

So when AVS check is turned on, the I only end up with the following warnings in the debug log:

[01-Aug-2019 00:48:54 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Charge instance: customer
[01-Aug-2019 00:48:54 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Charge instance: disputed
[01-Aug-2019 00:48:54 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Charge instance: invoice
[01-Aug-2019 00:48:54 Asia/Tokyo] Stripe Notice: Undefined property of Stripe_Object instance: typeSo the remaining properties (all *address_**) seem to have been used for AVS.

Enabling the option for creating a Stripe customer object did not change the remaining debug log output.
So I have no idea at the moment how these debug lines are related to the Stripe module options, and how to get rid of them.

Heh, I see in my Admin orders that Stripe orders have a tax of double what it should be, very odd. Will need to check how region and so on affects this. I only have one tax declared, Japanese VAT of 8%. So the Tax field in the order says 16%, but the Japanese VAT line in the total calculations correctly states 8%.
Other payment types (e.g., moneyorder) display 8% for the Tax field.
So not sure if that is a module issue, or a Stripe issue. More investigation needed.

Bah, I have two tax rates defined in the class VAT, one called "Japan", one called "Japan (Tokyo only)". This is for the case where I can only sell inside Tokyo. Since I did not define any payment zone for the Stripe module ("none"), it seems both these tax rates are taken together.
I will simply admit I do not understand this very well, and leave it at that for now.

Regarding Stripe API: I am running the latest API version, 2019-05-16.
Will be reading the documentation to see what possible differences there are.
https://stripe.com/docs/api/versioning
It says one can override the Stripe version, unfortunately I don't know what version v1.3.2 of the plugin was written for.
The API changelog is pretty long, frequent updates:
https://stripe.com/docs/upgrades#api-changelog

A guide to upgrading:
https://stripe.com/docs/upgrades

Lots to read in the API reference:
https://stripe.com/docs/api

Looking at the comment in the latest Stripe module version 1.3.4, and comparing the the changes in the Stripe API version listed in the link above, it appers v1.3.4 corresponds to the Stripe API version 2015-02-18.
So there is quite a lot of history to go through in updating.

I would suggest rewriting this Stripe module instead of trying to repair it. Not only this module uses to the old (soon defunct) API to process payment, it also cannot support the latest security requirement.

My skill is limited and the API is somewhat confusing to me. The easiest way is probably to integrate Stripe Checkout as a new module. If you can do it, it'd be great. Seems the deadline is Sept 14th for the SCA payment requirement.

Hi Alex,
I'm afraid writing a new module is way beyond my current capabilities, and the timeline I need to meet to use the functionality. Writing payment processor modules is definitely something I would like to do in future though, so fixing the Stripe module in stages seemed like a good start, and I am moving ahead reading the API docs little by little as I find the time.
I really don't care if all the functionality is not available (I doubt it was in the old module either), but I am worried by my lack of understanding in that I won't be able to tell if I have overlooked something critical.
Anyhow, if you have some insight/suggestions in that regard, please chime in, two pairs of eyes (and two brains) is better than one.

BTW what is the soon to be defunct API? Stripe versions its REST API, so I don't see what is going to be defunct there.

We actually are using the module without problem (installed this at least 4 or 5 years ago), only made some minimum adjustment (mostly on the variables Stripe changed in the API over the years).

Quite a few of our clients are euro-based, so we are looking for a SCA solution. And the old Charge API is working but not what we need.

Got it. For European users indeed SCA support will be required. For me in Japan, not the case, so an easier bullet to bite.

Just wondering if there has been any development on this. 2 weeks time SCA will be required and all cards will get declined if SCA not set up. Has anyone got a working solution? Or is it a case of setting up anther payment solution such as Paypal to avoid any problem?

Running ZC Version: v1.5.6c
And latest stripe module.

Every time I attempt to process a card outside of test mode I get the following notification:

Must provide source or customer.

Has anyone come up with a fix for this?