Hard coded payment options in Stripe
I'd like to propose a change from hard coded payment options in stripe connector to a flexible solution. Currently, with every version update payment options have to be added in the array manually, again.
-
- · OneEagle
- ·
Hi @thomlin
I wonder why do you ever need to add Stripe payment method types manually in a file? Aren't they added automatically in the Stripe integration with UNA?
Sorry for asking, it's because I am having a weird issue while testing Stripe (probably a setting issue). The payment methods I enabled in my Stripe account dashboard are not showing on my UNA site. Only the 'Card' method is available on my UNA Checkout.
@Anton L, after enabling payment methods from the Stripe account dashboard, do we still need to add them manually in the BxPaymentProviderStripeV3.php file?
If so, every time there will be a UNA update, we will have to edit that file manually again to put back those payment methods, right?
Can't we have an option in the UNA payment settings where the admin can select which payment methods should be available for Stripe and that information saved into the database?
Thanks
-
- · thomlin
-
·
In reply to OneEagle
- ·
That's because Stripe offers a vast number of different payment methods. Credit Cards are globally means of payment. Therefore it's rather safe to hardcode it as the only predefined option. For every other payment method you configured in your Stripe account, you have to add it by its name code manually to the payment types array in una stripe connection.
Since the stripe connection is part of the una core, it's necessary to update your payment methods in the connector after an update, again and again. That's why I asked for a better solution, if that can be done (because for full automation the connector would have to have permission to read payment methods from a stripe account or you do the dirty hack and ask the user in a studio form, which payment methods he has defined and then the system replaces this input in the payment types array in una code dynamically).
-
- · OneEagle
- ·
Thanks a lot for your reply. Sure, a flexible solution is definately needed here.
You don't have to ask members to enter the Stripe payment method types. That way, managing them will be difficult as there are plenty availabe.
From the frontend, users should just see Stripe as an available payment option beside Paypal, Chargebee, Credits etc. It's the admin (from the backend) who will have to set all the Stripe payment method types to be used on the website globally: Studio -> Stripe module. Members who choose Stripe will automatically be using them.
BTW, I have checked, there are about 30 of them. See: https://stripe.com/docs/api/payment_methods/object
This shouldn't be very difficult to implement either as single quotes comma-separated values into a text input field, a multiline field or as a multiple-selection list box.
Hopeful @Anton L will jump in and advise.
Thanks
-
- · thomlin
-
·
In reply to OneEagle
- ·
Oh, I didn't mean members, sorry. As "Users" I meant UNA framework users, or admins. I totally agree with you that the current solution is not a very satisfying one.
But, as always with 3rd-party-integrations, from the devs perspective, they try to keep it as simple as possible, cause you never know whats gonna happen, when the 3rd-party decides to make fundamental changes to their apis or processes.
I'm pretty sure that the devs will discuss a more practicabel solution than the actual one.
-
Yeah, I got you. Thanks
-
-
·
Anton L
- ·
Hello
By default integration uses only 'card' payment type. But you may customize the Session description array by using an alert. In this case you don't need to modify core files.
bx_alert($this->_oModule->_oConfig->getName(), $this->_sName . '_create_session', 0, false, array( 'session_object' => &$oSession, 'session_params' => &$aSession ));It's a common way in UNA to make customizations without any changes in default files.
-
·
Anton L
-
- · thomlin
-
·
In reply to Anton L
- ·
Could you demonstrate that with the current example of adding more payment types to the v3 stripe connection, please?
-
- · OneEagle
-
·
In reply to Anton L
- ·
Yes @Anton L, Please could you be more specific?
-
-
·
Anton L
- ·
Hello.
The customization can be done via custom module only. So, first of all you need to create your own custom module. More info about it here. You don't need to create any pages, menus, etc. Just an empty module which can be installed/uninstalled, enabled/disabled via Studio.
P.S. If you'll take the challenge and create working empty custom module I'll continue with instructions. 😉
-
·
Anton L
-
- · thomlin
-
·
In reply to Anton L
- ·
Thank you, Anton. I accept the challenge, since I'll need some practice on modification of modules in future, anyways. It's the right time for me to step in.
-
- · Peter
-
·
In reply to thomlin
T
- ·
You could start with an empty language module to step in😎
-
- · thomlin
-
·
In reply to Peter
- ·
That's on my list, since the old translation modules are faulty with UNA13. But translating 15k+ language keys beforehand is like a part-time job.
-
- · thomlin
-
·
In reply to Anton L
- ·
Ready for the next lession, @Anton L . Simple module installed.
-
- · OneEagle
-
·
In reply to Anton L
- ·
P.S. If you'll take the challenge and create working empty custom module I'll continue with instructions. 😉
That was ironic though! @Anton L It will be difficult and many of us won't make it.
Please, would you mind just providing for the solution to this issue and improve the way the Stripe payment method system works in UNA? Please can you create that custom module with all the code needed to fix this problem and make it available for download on the marketplace?
I think It is not a good pratice having the Stripe Payment Method Types hard-coded (added in a file manually) and overridden whenever there is a UNA update.
What about if someone forget to manually re-apply the changes after a UNA update, then the payment method types won't be available to members anymore.
IMHO, this is a crucial aspect of the UNA payment system. The solution should be added to the UNA core features. Thanks in advance for your understanding.
-
- · thomlin
-
·
In reply to OneEagle
- ·
I'll share it on apps market as soon as it's finished for free. That way, I can have my lessons and everyone else the final solution. Deal?
-
Thanks
-
-
·
Anton L
-
·
In reply to thomlin
T
- ·
I'll share it on apps market as soon as it's finished for free. That way, I can have my lessons and everyone else the final solution. Deal?
Hello. OK, @thomlin lets continue our lesson. :)
1. You need to register a handler for 'stripe_v3_create_session' alert from 'Payments' module. I'll use the following names and prefixes in my example:
- module's verndor - tester
- module name - bx_dummy
- module folder - dummy
- module class prefix - BxDummy
So, you need add the following code in enable.sql of your custom app.
INSERT INTO `sys_alerts_handlers` (`name`, `class`, `file`, `service_call`) VALUES ('bx_dummy', 'BxDummyAlertsResponse', 'modules/tester/dummy/classes/BxDummyAlertsResponse.php', ''); SET @iHandler := LAST_INSERT_ID(); INSERT INTO `sys_alerts` (`unit`, `action`, `handler_id`) VALUES ('bx_payment', 'stripe_v3_create_session', @iHandler);and this one in disable.sql
SET @iHandler := (SELECT `id` FROM `sys_alerts_handlers` WHERE `name` = 'bx_dummy' LIMIT 1); DELETE FROM `sys_alerts` WHERE `handler_id` = @iHandler; DELETE FROM `sys_alerts_handlers` WHERE `id` = @iHandler;2. Now we need to create BxDummyAlertsResponse class in modules/tester/dummy/classes/BxDummyAlertsResponse.php file and process the alert. So, the file should have the following code:
<?php defined('BX_DOL') or die('hack attempt'); /** * Copyright (c) UNA, Inc - https://una.io * MIT License - https://opensource.org/licenses/MIT * * @defgroup The Art Collectors Club * @ingroup UnaModules * * @{ */ class BxDummyAlertsResponse extends BxDolAlertsResponse { protected $_sModule; protected $_oModule; public function __construct() { parent::__construct(); $this->_sModule = 'bx_dummy'; $this->_oModule = BxDolModule::getInstance($this->_sModule); } public function response($oAlert) { $sMethod = '_process' . bx_gen_method_name($oAlert->sUnit . '_' . $oAlert->sAction); if(!method_exists($this, $sMethod)) return; $this->$sMethod($oAlert); } protected function _processBxPaymentStripeV3CreateSession($oAlert) { $aSession = $oAlert->aExtras['session_params']; //TODO: Make your customizations here. $oAlert->aExtras['session_params'] = $aSession; } } /** @} */So, in this case $aSession variable will contain the array which you wanted to modify and thefore you need to do something like the following:
$aSession = $oAlert->aExtras['session_params']; $aSession['payment_method_types'] = array_merge($aSession['payment_method_types'], ['sofort', 'sepa_debit']); $oAlert->aExtras['session_params'] = $aSession;After that you need to disable/enable your app and test.
-
·
Anton L
-
- · thomlin
-
·
In reply to Anton L
- ·
@Anton L , if you were my lecturer in Software Engineering, decades ago, I'd have my master's study finished till the end. Great lesson, thanks!
-
-
·
Anton L
-
·
In reply to thomlin
T
- ·
You are very welcome and good luck with your customizations!
-
·
Anton L
-
- · thomlin
-
·
In reply to Anton L
- ·
$aSession variable contains the array and therefore, the former hardcoded array in class 'BxPaymentProviderStripeV3.php' has now to be substituted by the new variable, am I right?
-
-
·
Anton L
-
·
In reply to thomlin
T
- ·
$aSession variable contains the array and therefore, the former hardcoded array in class 'BxPaymentProviderStripeV3.php' has now to be substituted by the new variable, am I right?
Hello. Yes, the default array will be overwritten with the new one which is returned to $oAlert->aExtras['session_params']
$oAlert->aExtras['session_params'] = $aSession;It happens because this part of alert's aExtras array was passed by referrence in BxPaymentProviderStripeV3::_createSession method.
bx_alert($this->_oModule->_oConfig->getName(), $this->_sName . '_create_session', 0, false, array( 'session_object' => &$oSession, 'session_params' => &$aSession )); -
·
Anton L
-
- · thomlin
-
·
In reply to Anton L
- ·
If I got you right, the session parameter will overwrite the parameters hardcoded in the array in BxPaymentProviderStripeV3.php? So, no modification of BxPaymentProviderStripeV3.php needed anymore, right?
-
-
·
Anton L
-
·
In reply to thomlin
T
- ·
If I got you right, the session parameter will overwrite the parameters hardcoded in the array in BxPaymentProviderStripeV3.php? So, no modification of BxPaymentProviderStripeV3.php needed anymore, right?
Yes, you are right. All these were done to avoid direct changes in default 'BxPaymentProviderStripeV3.php' file.
-
·
Anton L
-
- · thomlin
-
·
In reply to Anton L
- ·
Dear @Anton L , it doesn't overwrite as I assumed, it merges (array_merge()) the parameters to existing hardcoded arguments in the array, as I just found out.
-
- · thomlin
-
·
In reply to thomlin
T
- ·
Now, that I set BxPaymentProviderStripeV3.php back to its original version, everything works like a charm! It's really magic. 🙌
When does the lesson "Extending the module with putting data into the array by using Studio settings" start? 😉
-
-
·
Anton L
-
·
In reply to thomlin
T
- ·
Now, that I set BxPaymentProviderStripeV3.php back to its original version, everything works like a charm! It's really magic. 🙌
When does the lesson "Extending the module with putting data into the array by using Studio settings" start? 😉
Hello. If you just want to control items of 'payment_method_types' parameter view Settings then it wouldn't be a problem. I mean to have a Dropdown with Card, Sofort and Sepa Debit choices.
-
·
Anton L
-
- · thomlin
-
·
In reply to Anton L
- ·
How about a comma-separated list of arguments to fill the array with, individually? Of corse, the user will be responsible to configure his payment methods in Stripe accordingly.
-
-
·
Anton L
-
·
In reply to thomlin
T
- ·
Yes, it can be done this way. In this case you may use standard Text field. It's even more easier.
-
·
Anton L