[Skip to main content](#vessel-content)
# Profile for mail@quantumtouch.com
##
[](/forum/user/7996-mail-quantumtouch-com "View mail@quantumtouch.com's Profile")
**[ Offline](/forum/user/7996-mail-quantumtouch-com)**
- **User Type:** User
- **Register Date:** 27 Jun 2012
- **Last login:** 4 months 1 week ago
- **Time Zone:** UTC +0:00
- **Local Time:** 05:44
- **Posts:** 5
- **Profile views:** 123
- **Gender:** Unknown
- **Birthdate:** Unknown
- **Medals:** Hikashop Business
- Posts
# mail@quantumtouch.com's recent posts (5 messages )
All Since last visit 4 Hours 8 Hours 12 Hours 24 Hours 48 Hours Week Month Year All Since last visit 4 Hours 8 Hours 12 Hours 24 Hours 48 Hours Week Month Year
| [ ](#forumbottom) | Subject | Replies / Views | Last Post | [ ](#forumtop) |
|---|---|---|---|---|
| [](/forum/29-payment-methods/910542-paypal-checkout-buttons-only-appear-on-order-confirmation-page-not-on-payment-p#372039) | [PayPal Checkout buttons only appear on order confirmation page, not on payment p](/forum/29-payment-methods/910542-paypal-checkout-buttons-only-appear-on-order-confirmation-page-not-on-payment-p#372039 "-- HikaShop version -- : 6.4.1 -- Joomla version -- : 3.10.2 -- PHP version -- : 7.4.33 Hello, I am using the latest version of HikaShop with the PayPal Checkout plugin. I want the PayPal Smart Buttons to appear directly on the payment checkout page. However, they do not load there at all. When the customer is on the payment step, they only see the radio button and the payment description. The actual PayPal buttons only appear later, on the final order confirmation page. My checkout workflow has the Cart and Payment blocks configured together, but the buttons still refuse to render on the payment page. Could you please help me figure out how to make the PayPal buttons load directly on the payment step instead of the confirmation page? Thank you!") Category: [Payment Methods](/forum/29-payment-methods "Discussions about the different payment methods for Hikashop") Topic started 5 months 6 days ago, by [mail@quantumtouch.com](/forum/user/7996-mail-quantumtouch-com "View mail@quantumtouch.com's Profile") [Last Post](/forum/29-payment-methods/910542-paypal-checkout-buttons-only-appear-on-order-confirmation-page-not-on-payment-p#372041 "Hello, What you describe is doable as a custom plugin, and HikaShop actually gives you two clean places to render the buttons on the payment step, so you do not have to fight the checkout. Here is the architecture I would consider safest, point by point. Rendering the buttons on the payment step, two options: 1) Payment-plugin custom HTML (simplest, recommended to start). A payment plugin can output its own HTML in the payment block: implement onPaymentDisplay() and set $method->custom_html on your method. HikaShop renders that HTML under the method, and only when the method is selected, which is exactly where you want the buttons. Several gateways (Klarna, Alma, AfterPay, Atos...) already use this to inject their widgets at the payment step. 2) Checkout API custom block (more control over placement). If you would rather have the buttons as their own checkout block instead of tied to the payment method, register a block with the Checkout API: onCheckoutStepList() to declare it so it shows up in the checkout workflow configuration, onInitCheckoutStep() to prepare its data, and onCheckoutStepDisplay() to output its HTML (for layouts prefixed with "plg."). The merchant then drops your block wherever they want in the workflow. Start with option 1 (scoped to the method, shown on selection automatically); use option 2 if you need the buttons outside the payment-method list. createOrder, before any HikaShop order exists Compute the amount server-side from the current HikaShop cart (cart and currency classes), never from the client, and create the PayPal order for that amount in an endpoint of your plugin. At the same time, store a fingerprint of the cart (a hash of the line items, total and currency) in the HikaShop checkout session. That is your cart snapshot, re-checked at capture. Creating the HikaShop order in the approval callback Yes, creating the order only in the PayPal approval callback is the right choice to avoid early orders. Create it by going through HikaShop's own checkout order-creation path (the same one the confirmation step uses), not a hand-rolled insert, so every validation and every other plugin hooking order creation still runs. Before creating it, re-read the cart and compare to the fingerprint: if anything changed (price, stock, coupon, contents), abort and send the customer back. That "pay, then the cart changes" window is exactly what the standard end-of-checkout flow avoids by design. Then capture the payment server-side, verify the captured amount equals the order total, and on success redirect to that order's standard end/thanks page. Security points not to skip All amounts and the capture verification stay server-side; the client only carries the PayPal order id. You are effectively re-implementing the guarantees of HikaShop's confirmation step (terms acceptance, final stock/coupon/total validation, totals lock), and anything missed there becomes a consistency or security gap. Reuse the PayPal Checkout plugin's existing API class for create/capture instead of rewriting the PayPal calls; it already handles auth and the REST endpoints. On performance, the step stays light: the SDK and the createOrder call only fire when your method is selected, and createOrder is a single server call. The heavy work (validation, order creation, capture) happens once, on approval, so the page itself does not get slower. Skeleton to point you in the right direction (option 1, illustrative, not copy-paste ready): Net: plan for a fully custom plugin; the pieces you can safely reuse are the existing plugin's PayPal API class and HikaShop's standard order-creation path. If you would rather not re-implement the confirmation-step guarantees, the lower-risk alternative is to keep the standard flow and condense the checkout so the buttons appear as early as possible.") 5 months 4 days ago by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") | Replies:3 Views:304 | [Last Post](/forum/29-payment-methods/910542-paypal-checkout-buttons-only-appear-on-order-confirmation-page-not-on-payment-p#372041 "Hello, What you describe is doable as a custom plugin, and HikaShop actually gives you two clean places to render the buttons on the payment step, so you do not have to fight the checkout. Here is the architecture I would consider safest, point by point. Rendering the buttons on the payment step, two options: 1) Payment-plugin custom HTML (simplest, recommended to start). A payment plugin can output its own HTML in the payment block: implement onPaymentDisplay() and set $method->custom_html on your method. HikaShop renders that HTML under the method, and only when the method is selected, which is exactly where you want the buttons. Several gateways (Klarna, Alma, AfterPay, Atos...) already use this to inject their widgets at the payment step. 2) Checkout API custom block (more control over placement). If you would rather have the buttons as their own checkout block instead of tied to the payment method, register a block with the Checkout API: onCheckoutStepList() to declare it so it shows up in the checkout workflow configuration, onInitCheckoutStep() to prepare its data, and onCheckoutStepDisplay() to output its HTML (for layouts prefixed with "plg."). The merchant then drops your block wherever they want in the workflow. Start with option 1 (scoped to the method, shown on selection automatically); use option 2 if you need the buttons outside the payment-method list. createOrder, before any HikaShop order exists Compute the amount server-side from the current HikaShop cart (cart and currency classes), never from the client, and create the PayPal order for that amount in an endpoint of your plugin. At the same time, store a fingerprint of the cart (a hash of the line items, total and currency) in the HikaShop checkout session. That is your cart snapshot, re-checked at capture. Creating the HikaShop order in the approval callback Yes, creating the order only in the PayPal approval callback is the right choice to avoid early orders. Create it by going through HikaShop's own checkout order-creation path (the same one the confirmation step uses), not a hand-rolled insert, so every validation and every other plugin hooking order creation still runs. Before creating it, re-read the cart and compare to the fingerprint: if anything changed (price, stock, coupon, contents), abort and send the customer back. That "pay, then the cart changes" window is exactly what the standard end-of-checkout flow avoids by design. Then capture the payment server-side, verify the captured amount equals the order total, and on success redirect to that order's standard end/thanks page. Security points not to skip All amounts and the capture verification stay server-side; the client only carries the PayPal order id. You are effectively re-implementing the guarantees of HikaShop's confirmation step (terms acceptance, final stock/coupon/total validation, totals lock), and anything missed there becomes a consistency or security gap. Reuse the PayPal Checkout plugin's existing API class for create/capture instead of rewriting the PayPal calls; it already handles auth and the REST endpoints. On performance, the step stays light: the SDK and the createOrder call only fire when your method is selected, and createOrder is a single server call. The heavy work (validation, order creation, capture) happens once, on approval, so the page itself does not get slower. Skeleton to point you in the right direction (option 1, illustrative, not copy-paste ready): Net: plan for a fully custom plugin; the pieces you can safely reuse are the existing plugin's PayPal API class and HikaShop's standard order-creation path. If you would rather not re-implement the confirmation-step guarantees, the lower-risk alternative is to keep the standard flow and condense the checkout so the buttons appear as early as possible.") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") 5 months 4 days ago |
| [](/forum/29-payment-methods/910542-paypal-checkout-buttons-only-appear-on-order-confirmation-page-not-on-payment-p#372028) | [PayPal Checkout buttons only appear on order confirmation page, not on payment p](/forum/29-payment-methods/910542-paypal-checkout-buttons-only-appear-on-order-confirmation-page-not-on-payment-p#372028 "-- HikaShop version -- : 6.4.1 -- Joomla version -- : 3.10.2 -- PHP version -- : 7.4.33 Hello, I am using the latest version of HikaShop with the PayPal Checkout plugin. I want the PayPal Smart Buttons to appear directly on the payment checkout page. However, they do not load there at all. When the customer is on the payment step, they only see the radio button and the payment description. The actual PayPal buttons only appear later, on the final order confirmation page. My checkout workflow has the Cart and Payment blocks configured together, but the buttons still refuse to render on the payment page. Could you please help me figure out how to make the PayPal buttons load directly on the payment step instead of the confirmation page? Thank you!") Category: [Payment Methods](/forum/29-payment-methods "Discussions about the different payment methods for Hikashop") Topic started 5 months 6 days ago, by [mail@quantumtouch.com](/forum/user/7996-mail-quantumtouch-com "View mail@quantumtouch.com's Profile") [Last Post](/forum/29-payment-methods/910542-paypal-checkout-buttons-only-appear-on-order-confirmation-page-not-on-payment-p#372041 "Hello, What you describe is doable as a custom plugin, and HikaShop actually gives you two clean places to render the buttons on the payment step, so you do not have to fight the checkout. Here is the architecture I would consider safest, point by point. Rendering the buttons on the payment step, two options: 1) Payment-plugin custom HTML (simplest, recommended to start). A payment plugin can output its own HTML in the payment block: implement onPaymentDisplay() and set $method->custom_html on your method. HikaShop renders that HTML under the method, and only when the method is selected, which is exactly where you want the buttons. Several gateways (Klarna, Alma, AfterPay, Atos...) already use this to inject their widgets at the payment step. 2) Checkout API custom block (more control over placement). If you would rather have the buttons as their own checkout block instead of tied to the payment method, register a block with the Checkout API: onCheckoutStepList() to declare it so it shows up in the checkout workflow configuration, onInitCheckoutStep() to prepare its data, and onCheckoutStepDisplay() to output its HTML (for layouts prefixed with "plg."). The merchant then drops your block wherever they want in the workflow. Start with option 1 (scoped to the method, shown on selection automatically); use option 2 if you need the buttons outside the payment-method list. createOrder, before any HikaShop order exists Compute the amount server-side from the current HikaShop cart (cart and currency classes), never from the client, and create the PayPal order for that amount in an endpoint of your plugin. At the same time, store a fingerprint of the cart (a hash of the line items, total and currency) in the HikaShop checkout session. That is your cart snapshot, re-checked at capture. Creating the HikaShop order in the approval callback Yes, creating the order only in the PayPal approval callback is the right choice to avoid early orders. Create it by going through HikaShop's own checkout order-creation path (the same one the confirmation step uses), not a hand-rolled insert, so every validation and every other plugin hooking order creation still runs. Before creating it, re-read the cart and compare to the fingerprint: if anything changed (price, stock, coupon, contents), abort and send the customer back. That "pay, then the cart changes" window is exactly what the standard end-of-checkout flow avoids by design. Then capture the payment server-side, verify the captured amount equals the order total, and on success redirect to that order's standard end/thanks page. Security points not to skip All amounts and the capture verification stay server-side; the client only carries the PayPal order id. You are effectively re-implementing the guarantees of HikaShop's confirmation step (terms acceptance, final stock/coupon/total validation, totals lock), and anything missed there becomes a consistency or security gap. Reuse the PayPal Checkout plugin's existing API class for create/capture instead of rewriting the PayPal calls; it already handles auth and the REST endpoints. On performance, the step stays light: the SDK and the createOrder call only fire when your method is selected, and createOrder is a single server call. The heavy work (validation, order creation, capture) happens once, on approval, so the page itself does not get slower. Skeleton to point you in the right direction (option 1, illustrative, not copy-paste ready): Net: plan for a fully custom plugin; the pieces you can safely reuse are the existing plugin's PayPal API class and HikaShop's standard order-creation path. If you would rather not re-implement the confirmation-step guarantees, the lower-risk alternative is to keep the standard flow and condense the checkout so the buttons appear as early as possible.") 5 months 4 days ago by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") | Replies:3 Views:304 | [Last Post](/forum/29-payment-methods/910542-paypal-checkout-buttons-only-appear-on-order-confirmation-page-not-on-payment-p#372041 "Hello, What you describe is doable as a custom plugin, and HikaShop actually gives you two clean places to render the buttons on the payment step, so you do not have to fight the checkout. Here is the architecture I would consider safest, point by point. Rendering the buttons on the payment step, two options: 1) Payment-plugin custom HTML (simplest, recommended to start). A payment plugin can output its own HTML in the payment block: implement onPaymentDisplay() and set $method->custom_html on your method. HikaShop renders that HTML under the method, and only when the method is selected, which is exactly where you want the buttons. Several gateways (Klarna, Alma, AfterPay, Atos...) already use this to inject their widgets at the payment step. 2) Checkout API custom block (more control over placement). If you would rather have the buttons as their own checkout block instead of tied to the payment method, register a block with the Checkout API: onCheckoutStepList() to declare it so it shows up in the checkout workflow configuration, onInitCheckoutStep() to prepare its data, and onCheckoutStepDisplay() to output its HTML (for layouts prefixed with "plg."). The merchant then drops your block wherever they want in the workflow. Start with option 1 (scoped to the method, shown on selection automatically); use option 2 if you need the buttons outside the payment-method list. createOrder, before any HikaShop order exists Compute the amount server-side from the current HikaShop cart (cart and currency classes), never from the client, and create the PayPal order for that amount in an endpoint of your plugin. At the same time, store a fingerprint of the cart (a hash of the line items, total and currency) in the HikaShop checkout session. That is your cart snapshot, re-checked at capture. Creating the HikaShop order in the approval callback Yes, creating the order only in the PayPal approval callback is the right choice to avoid early orders. Create it by going through HikaShop's own checkout order-creation path (the same one the confirmation step uses), not a hand-rolled insert, so every validation and every other plugin hooking order creation still runs. Before creating it, re-read the cart and compare to the fingerprint: if anything changed (price, stock, coupon, contents), abort and send the customer back. That "pay, then the cart changes" window is exactly what the standard end-of-checkout flow avoids by design. Then capture the payment server-side, verify the captured amount equals the order total, and on success redirect to that order's standard end/thanks page. Security points not to skip All amounts and the capture verification stay server-side; the client only carries the PayPal order id. You are effectively re-implementing the guarantees of HikaShop's confirmation step (terms acceptance, final stock/coupon/total validation, totals lock), and anything missed there becomes a consistency or security gap. Reuse the PayPal Checkout plugin's existing API class for create/capture instead of rewriting the PayPal calls; it already handles auth and the REST endpoints. On performance, the step stays light: the SDK and the createOrder call only fire when your method is selected, and createOrder is a single server call. The heavy work (validation, order creation, capture) happens once, on approval, so the page itself does not get slower. Skeleton to point you in the right direction (option 1, illustrative, not copy-paste ready): Net: plan for a fully custom plugin; the pieces you can safely reuse are the existing plugin's PayPal API class and HikaShop's standard order-creation path. If you would rather not re-implement the confirmation-step guarantees, the lower-risk alternative is to keep the standard flow and condense the checkout so the buttons appear as early as possible.") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") 5 months 4 days ago |
| [](/forum/39-affilation/873649-will-affiliates-get-created-for-their-own-purchase#183491) | [Will affiliates get created for their own purchase](/forum/39-affilation/873649-will-affiliates-get-created-for-their-own-purchase#183491 "-- HikaShop version -- : 2.3.1 -- Joomla version -- : 3.2.0 -- PHP version -- : 5.5.13 Can an affiliate use their own affiliate link to get credit for their own purchase?") Category: [Affilation](/forum/39-affilation "Discussions related to the Affiliation system") Topic started 11 years 10 months ago, by [mail@quantumtouch.com](/forum/user/7996-mail-quantumtouch-com "View mail@quantumtouch.com's Profile") [Last Post](/forum/39-affilation/873649-will-affiliates-get-created-for-their-own-purchase#183535 "Hi, Yes it's possible. In the plugin (plugins/system/hikashopaffiliation/hikashopaffiliation.php) please replaceByI just submit same kind of patch for the next HikaShop release but where the default setting for the setting is "0" and not "1" (so the option won't be activated by default like here). Regards,") 11 years 10 months ago by [Jerome](/forum/user/80-jerome "View Jerome's Profile") | Replies:3 Views:1512 | [Last Post](/forum/39-affilation/873649-will-affiliates-get-created-for-their-own-purchase#183535 "Hi, Yes it's possible. In the plugin (plugins/system/hikashopaffiliation/hikashopaffiliation.php) please replaceByI just submit same kind of patch for the next HikaShop release but where the default setting for the setting is "0" and not "1" (so the option won't be activated by default like here). Regards,") by [Jerome](/forum/user/80-jerome "View Jerome's Profile") 11 years 10 months ago |
| [](/forum/39-affilation/873649-will-affiliates-get-created-for-their-own-purchase#183312) | [Will affiliates get created for their own purchase](/forum/39-affilation/873649-will-affiliates-get-created-for-their-own-purchase#183312 "-- HikaShop version -- : 2.3.1 -- Joomla version -- : 3.2.0 -- PHP version -- : 5.5.13 Can an affiliate use their own affiliate link to get credit for their own purchase?") Category: [Affilation](/forum/39-affilation "Discussions related to the Affiliation system") Topic started 11 years 10 months ago, by [mail@quantumtouch.com](/forum/user/7996-mail-quantumtouch-com "View mail@quantumtouch.com's Profile") [Last Post](/forum/39-affilation/873649-will-affiliates-get-created-for-their-own-purchase#183535 "Hi, Yes it's possible. In the plugin (plugins/system/hikashopaffiliation/hikashopaffiliation.php) please replaceByI just submit same kind of patch for the next HikaShop release but where the default setting for the setting is "0" and not "1" (so the option won't be activated by default like here). Regards,") 11 years 10 months ago by [Jerome](/forum/user/80-jerome "View Jerome's Profile") | Replies:3 Views:1512 | [Last Post](/forum/39-affilation/873649-will-affiliates-get-created-for-their-own-purchase#183535 "Hi, Yes it's possible. In the plugin (plugins/system/hikashopaffiliation/hikashopaffiliation.php) please replaceByI just submit same kind of patch for the next HikaShop release but where the default setting for the setting is "0" and not "1" (so the option won't be activated by default like here). Regards,") by [Jerome](/forum/user/80-jerome "View Jerome's Profile") 11 years 10 months ago |
| [](/forum/3-bug-report/85355-created-a-new-badge-issue#114001) | [Created a new badge issue!](/forum/3-bug-report/85355-created-a-new-badge-issue#114001 "Hi support, I would like to report a bug. When I finish to create a badge and I am going to save it, I get this message: "Error Saving", and does not save. I took a look in the code and noticed that it misses a field called "badge_url" in the data base. Problably because in this file: "administrator\components\com_hikashop\views\badge\tmpl\form.php line 121 to 128 " there are code lines that there are not supposed to be there. Thanks.") Category: [Bug Report](/forum/3-bug-report "Please report any bugs or errors here.") Topic started 13 years 3 months ago, by [mail@quantumtouch.com](/forum/user/7996-mail-quantumtouch-com "View mail@quantumtouch.com's Profile") [Last Post](/forum/3-bug-report/85355-created-a-new-badge-issue#114009 "Hi, It seems that the field wasn't added properly with the latest version that you installed. You can run the query below to add it manually via your phpmyadmin: ALTER TABLE `#__hikashop_badge` ADD `badge_url` VARCHAR( 255 ) NULL DEFAULT ''; Make sure that you replace the #__ by your table prefix.") 13 years 3 months ago by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") | Replies:1 Views:1455 | [Last Post](/forum/3-bug-report/85355-created-a-new-badge-issue#114009 "Hi, It seems that the field wasn't added properly with the latest version that you installed. You can run the query below to add it manually via your phpmyadmin: ALTER TABLE `#__hikashop_badge` ADD `badge_url` VARCHAR( 255 ) NULL DEFAULT ''; Make sure that you replace the #__ by your table prefix.") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") 13 years 3 months ago |
[](/forum/topics/feed/mode-topics?format=feed&type=rss)
Time to create page: 0.111 seconds
[Powered by](/forum/credits) [Kunena Forum](https://www.kunena.org)
[](#top)