Zen Cart Logo
Forums / Setting Up Categories, Products, Attributes / Different payment methods for different products

Different payment methods for different products

Views: 3,466

Results 1 to 15 of 15
29 Aug 2012, 12:50 AM
#1
smithdp1 avatar

smithdp1

New Zenner

Join Date:
Feb 2011
Posts:
33
Plugin Contributions:
0

Different payment methods for different products

I am working on a site that sells shipped goods only. They also offer a 6 month subscription to one of there products. If a customer buys a 6 month subscription, they want the persons credit card to be charged every month for the next 6 months and the order to go through the store once a month for the next 6 months. They are using authorize.net as the payment processor.

Here is the problem I face. I have downloaded and installed the Authorize.NET ARB Module.

When i try to set it up all is fine. When I enable it, it will show up as a payment option for all products at checkout. How can I have this only enabled for the subscription based product.

I also need help on how to restrict purchase of other products if the subscription is in the cart.

Help is really appreciated!

29 Aug 2012, 3:59 PM
#2
drbyte avatar

drbyte

Sensei

Join Date:
Jan 2004
Posts:
63,513
Plugin Contributions:
176

Re: Different payment methods for different products

You'll need several things:

a) a means of telling the software which items should be allowed for a particular module.
Is this list going to change frequently? If you need admin-side controls, this gets more complicated than if you can just hard-code product id numbers into a PHP file in something like a define() statement.

b) then tell that module to check the cart contents for anything that's not in that list, and disable itself if the test fails.
There is an update_status() method in the payment module's class file where this logic can be programmed. You'll need to get the list of products from the $_SESSION['cart'] object, and loop through them to look for matches from (a) above, and then set the $this->enabled to false if the test fails.

c) then if there's a problem, add some messaging to the customer to explain the problem, so they can alter the contents of their cart accordingly.
$messageStack calls can handle this. Maybe an observer class to look for certain checkout-related notifiers might be a good way to provide hints before they even start checkout.

29 Aug 2012, 4:04 PM
#3
smithdp1 avatar

smithdp1

New Zenner

Join Date:
Feb 2011
Posts:
33
Plugin Contributions:
0

Re: Different payment methods for different products

DrByte, thank you for taking the time. You have been very helpful.

Is this list going to change frequently? - No this will never change.

So where do I start? Are there any examples of this?

My product page is here(hope Im not breaking any rules) http://k9-gh.com/store/products-ezp-4.html

29 Aug 2012, 10:03 PM
#4
limitless avatar

limitless

Inactive

Join Date:
Jan 2012
Posts:
496
Plugin Contributions:
0

Re: Different payment methods for different products

Sorry OP, No help, just commiserating...

I hope some one develops a recurring billing/autoship module for ZenCart.

30 Aug 2012, 11:41 AM
#5
drbyte avatar

drbyte

Sensei

Join Date:
Jan 2004
Posts:
63,513
Plugin Contributions:
176

Re: Different payment methods for different products

Limitless,
Rather than merely commiserate with a "me too", perhaps you can start a thread in the Features Wish List section and clearly explain ALL the required components of the feature you seek. A complete list of everything needed, from every angle, to accomplish what you specifically seek.

Any feature starts with that. Somebody's gotta write it. And your needs will be unique to you, but if you start a discussion then it opens it up to crowd-sourcing of the broader project specifications that include the feature components that others need too. And if you model the discussion by giving granular details and invite others to also add granular details (not just a "me too"), then at some point a programmer might be able to take it and turn it into code.

But your post basically just says "I wish someone else would do all the thinking and all the work, so that I don't have to. And then when it doesn't work like I wanted I can safely complain that it's crap and they shoulda been smarter, not to mention able to figure out all of what my specific business needs, but without my crystal ball." Sorry, a bit of sarcasm added to demonstrate what it feels like for a programmer to read your detail-less post.

30 Aug 2012, 12:32 PM
#6
drbyte avatar

drbyte

Sensei

Join Date:
Jan 2004
Posts:
63,513
Plugin Contributions:
176

Re: Different payment methods for different products

smithdp1:

DrByte, thank you for taking the time. You have been very helpful.

Is this list going to change frequently? - No this will never change.

So where do I start? Are there any examples of this?

My product page is here(hope Im not breaking any rules) http://k9-gh.com/store/products-ezp-4.html

@**smithdp1:
**Here's something that might work for your specific case. Create and upload the following 2 files:

  1. /includes/classes/observers/class.subscriptionProductInCart.php
<?php
/**
 * @package plugins
 * @copyright Copyright 2003-2012 Zen Cart Development Team
 * @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
 *
 * Designed for v1.5.0. Tested on v1.5.0. Should work for v1.3.9 also.
 */
/**
 * If a customer adds the specified autoship subscription product to their shopping cart it should not allow them to add any other products.
 * If they try, a message is displayed saying the item has to be purchased by itself. Or vice-versa
 */
class subscriptionProductInCart extends base
{
  var $subscProductID = 4; // The product ID which is a subscription item

  function __construct ()
  {
    $_SESSION['cart']->attach($this, array(
                    'NOTIFIER_CART_ADD_CART_END' ,
                    'NOTIFIER_CART_REMOVE_END',
                    'NOTIFIER_CART_GET_PRODUCTS_END'));
  }

  function update (&$class, $eventID, $paramsArray = array())
  {
    global $messageStack;
    static $alertSent = FALSE;
    // Is $subscProductID in the cart?
    if ($_SESSION['cart']->in_cart($this->subscProductID) == TRUE) {
      // Is $subscProductID the only product? Are there more?
      if ($_SESSION['cart']->count_contents() > 1) {
        // If more than the one product in cart, disallow checkout
        $_SESSION['valid_to_checkout'] = false;
        if ($alertSent == FALSE) $messageStack->add_session('shopping_cart', SUBSCRIPTION_PROD_CANNOT_MIX_WITH_OTHER_PRODS, 'error');
        $alertSent = TRUE;
      } else {
        // $subscProductID is the only product, so okay for checkout
        if ($alertSent == FALSE) $messageStack->add_session('shopping_cart', SUBSCRIPTION_PROD_OKAY_PROCEED_TO_CHECKOUT, 'success');
        $alertSent = TRUE;
      }
    }
  }
}


if (!defined('SUBSCRIPTION_PROD_CANNOT_MIX_WITH_OTHER_PRODS')) define ('SUBSCRIPTION_PROD_CANNOT_MIX_WITH_OTHER_PRODS', 'ALERT: You cannot have autoship products AND non-autoship products in the same purchase. Please adjust your shopping basket contents before proceeding to checkout.');
if (!defined('SUBSCRIPTION_PROD_OKAY_PROCEED_TO_CHECKOUT')) define ('SUBSCRIPTION_PROD_OKAY_PROCEED_TO_CHECKOUT', 'Your autoship selections are ready for purchase. Please proceed to checkout now.');
  1. /includes/auto_loaders/config.subscriptionProductInCart.php
<?php
/**
 *
 * @package plugins
 * @copyright Copyright 2003-2012 Zen Cart Development Team
 * @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
 */
/**
 * Designed for v1.5.0, compatible with 1.3.9 also.
 */
if (!defined('IS_ADMIN_FLAG')) {
 die('Illegal Access');
}
$autoLoadConfig[190][] = array('autoType'=>'class',
                              'loadFile'=>'observers/class.subscriptionProductInCart.php');
$autoLoadConfig[190][] = array('autoType'=>'classInstantiate',
                              'className'=>'subscriptionProductInCart',
                              'objectName'=>'subscriptionProductInCart');
  1. Then make an edit to your authnet ARB module:
    Find the "function update_status" section, and add the code shown:```
    function update_status() {
    global $order, $db;

     if ( ($this->enabled == true) && ((int)MODULE_PAYMENT_AUTHORIZENET_ARB_ZONE > 0) ) {
       $check_flag = false;
    
       ///////// NOTE: there's a bunch more stuff here, removed from this post just for brevity because it's unrelated to the changes being pointed out below
    
       if ($check_flag == false) {
         $this->enabled = false;
       }
     }
     [B]
     if (($this->enabled == true)) {
       $this->subscProductID = 4; // the subscription product ID
       // If the subscription item isn't in the cart, or if there is more than one item in the cart, then disable this module so it doesn't appear during this checkout, unless they update their basket 
       if ($_SESSION['cart']->in_cart($this->subscProductID) == FALSE || $_SESSION['cart']->count_contents() > 1) {
         $this->enabled = FALSE;
       }
     }
     [/B]
    

    }

18 Oct 2012, 6:54 PM
#7
limitless avatar

limitless

Inactive

Join Date:
Jan 2012
Posts:
496
Plugin Contributions:
0

Re: Different payment methods for different products

DrByte:

Limitless,
Rather than merely commiserate with a "me too", perhaps you can start a thread in the Features Wish List section and clearly explain ALL the required components of the feature you seek. A complete list of everything needed, from every angle, to accomplish what you specifically seek.

Any feature starts with that. Somebody's gotta write it. And your needs will be unique to you, but if you start a discussion then it opens it up to crowd-sourcing of the broader project specifications that include the feature components that others need too. And if you model the discussion by giving granular details and invite others to also add granular details (not just a "me too"), then at some point a programmer might be able to take it and turn it into code.

But your post basically just says "I wish someone else would do all the thinking and all the work, so that I don't have to. And then when it doesn't work like I wanted I can safely complain that it's crap and they shoulda been smarter, not to mention able to figure out all of what my specific business needs, but without my crystal ball." Sorry, a bit of sarcasm added to demonstrate what it feels like for a programmer to read your detail-less post.

Ok, How about on every other website I have purchased a 'recurring' items on, ie theme site subscription, etc. the payment module (typically paypal) allows for it, whether that is monthly or yearly subscription.

Paypal has the API/ info published on how to do it, not sure on the recurrence settings (monthly/yearly) but it is capable of it. I have no idea 'what' is required from the ZenCart side of things to do that, but I would think monthly, yearly, set length of recurrence 2-12x, indefinite, etc.

Hell, most CC processors have the ability to do recurring billing as well, or even '3 easy payments of XXX'.

I am not sure of the requirements of every single person, but those would be the basics required of a modern payment module.

18 Oct 2012, 9:45 PM
#8
drbyte avatar

drbyte

Sensei

Join Date:
Jan 2004
Posts:
63,513
Plugin Contributions:
176

Re: Different payment methods for different products

Riddle me this: How would you tell Zen Cart to "magically insert an order" for something that occurs externally via the payment gateway? And if you were to tell Zen Cart to just "guess" that the recurring payment hasn't been cancelled, then how would you "marry up" the two sides?
Or do you want Zen Cart to just completely ignore the "repeat" and just let the payment gateway do its multiple billing, without ever generating an order/invoice for the subsequents?

Those are the things that need more details.

It's a no-brainer to simply pass additional parameters to the payment gateway so that it knows to keep billing the customer. It's the proper generation of orders/invoices to match those repeat billings that's the "problem".
And since every storeowner has different ideas how it should work, and every payment gateway has varying levels of sophistication in terms of ability to tell the store that another payment has been collected, it's a huge task to write code that handles every possible scenario ... cuz as soon as we put out a "limited" module that only handles things "one way", we'll get a thousand people complaining that it's inadequate because it doesn't handle it "their way".
The secondary aspect is the need to write custom data schema and custom product-type requirements to manage all the possible combinations of repeats that are needed for any given product. (downpayment with or without X additional payments, "X" equal payments, "XX" amount every month/quarter/year, ending date if any, etc, etc, etc) And if something is supposed to happen inside Zen Cart (ie: renews membership access to a certain aspect of website, etc), how will Zen Cart know about that, especially if the payment gateway doesn't have a notification tool to tell the store about the completed renewal payment? What about the merchant who refuses to pay for the additional monthly fee charged by many gateways when recurring billing is added to their account?...should Zen Cart provide some sort of makeshift "simulated recurring billing" that emails the customer about their expiry and gives a link to bring them back to the store to re-buy by supplying their card data as part of a new purchase? (that'll require a bunch of specialized infrastructure too) ... and the list goes on.

Those are more things that need more details ;)

So, this is really another invitation to crowd-source the specs that would work for the broadest range of merchant requirements around the globe, so that the code could be written to suit those needs. If the people "wanting" it would explain the complete big picture of ALL they need it to do, that would shorten the amount of research required and allow the coders to write code to meet the requirements.

Until then it's probably gonna be just what it's always been: individual merchants write something bespoke for their individual needs, and rarely share it with the community.

Care to start the Features Wish List discussion to collect the broadest range of (highly-detailed) information on all the myriad aspects of what they would need?

19 Oct 2012, 5:06 AM
#9
limitless avatar

limitless

Inactive

Join Date:
Jan 2012
Posts:
496
Plugin Contributions:
0

Re: Different payment methods for different products

Authorize.Net: http://www.authorize.net/solutions/merchantsolutions/merchantservices/automatedrecurringbilling/
Paypal: https://www.paypal.com/cgi-bin/webscr?cmd=_payflow-recurring-billing-overview-outside
Vindicia: http://www.vindicia.com/products/CashBox.html

Payment processors have API's for the most common requirements of this functionality. If you need it for a different processor or something outside the norm (ie you as a store owner think it 'should' work differently) then I can see where it gets weird, but if SagePay doesn't support it or doesn't publish an API, then a 'wishlist feature' could be crowd-sourced to perhaps organize a campaign of store owners to pester said processor to support something, but these are available APIs with out of the box, vendor perceived 'normal' functionality. But if the processor has a published way they do it, a module could support that. If a store owner wants to charge someone every 18 days vs ,omthly, well, that would be a 'feature request' of the processor, not the module that uses published vendor APIs.

Amazon Payments, Google Checkout, Paypal and Dwolla modules seem to stay up to date with the changes the vendor enforces, generally its not the module that forces a vendor to behave a certain way but vice versa. If some processor doesn't support a feature ie recurring billing and I need it, I will move on to one that does. Membership site functionality would be a 'wishlist item', esp regarding digital downloads, etc., but in regards to something like Amazon's Prime it would be awesome (and a huge undertaking), but for something like layaway, recurring billing is the norm.

What drew me to zencart was the 'free' functionality via modules, but I also see value in paid modules that extend the functionality and have and will willingly pay for such functionality (similar to Magento and Prestashop). Perhaps opening the modules section up or creating a marketplace for paid modules will encourage some of the zencart gurus to extend things further.

4 Aug 2013, 6:29 PM
#10
zoftheashes avatar

zoftheashes

New Zenner

Join Date:
Jun 2011
Posts:
15
Plugin Contributions:
0

Re: Different payment methods for different products

@Dr. Byte:
I would love to use your purposed solution to smithdp1's problem only modifying it to work with CEON's Manual Card plugin. My client only wants to use Paypal and already subscribes to their Virtual Terminal service as he also sells a decent amount over the phone which is why I think this solution would be a good match. However before I begin muddling around I wanted to get your thoughts. Any feed back would be greatly appreciated.

4 Aug 2013, 6:47 PM
#11
zoftheashes avatar

zoftheashes

New Zenner

Join Date:
Jun 2011
Posts:
15
Plugin Contributions:
0

Re: Different payment methods for different products

I would love to use your purposed solution to smithdp1's problem only modifying it to work with CEON's Manual Card plugin. My client only wants to use Paypal and already subscribes to their Virtual Terminal service as he also sells a decent amount over the phone which is why I think this solution would be a good match. However before I begin muddling around I wanted to get your thoughts. Any feed back would be greatly appreciated

6 Aug 2013, 8:27 PM
#12
drbyte avatar

drbyte

Sensei

Join Date:
Jan 2004
Posts:
63,513
Plugin Contributions:
176

Re: Different payment methods for different products

Pretty much the same concept applies.

I haven't looked at that CEON module in quite awhile, but since it's built with the same main structure, the same principles would apply.

14 Aug 2014, 12:10 AM
#13
marcopolo avatar

marcopolo

Totally Zenned

Join Date:
May 2008
Location:
United States
Posts:
520
Plugin Contributions:
2

Re: Different payment methods for different products

DrByte I would like to open this up for discussion and create a wish list of features a subscription auto order type module should have. Has anyone else already started it? From the last post on this thread it seems like it has been over a year since it was last discussed.

14 Aug 2014, 1:55 AM
#14
mc12345678 avatar

mc12345678

Totally Zenned

Join Date:
Jul 2012
Posts:
16,908
Plugin Contributions:
2

Re: Different payment methods for different products

marcopolo:

DrByte I would like to open this up for discussion and create a wish list of features a subscription auto order type module should have. Has anyone else already started it? From the last post on this thread it seems like it has been over a year since it was last discussed.

I think I would encourage looking through the forum section regarding a wishlist. That is the area that Dr. Byte suggested others either begin or continue such a discussion.