Different payment methods for different products

[smithdp1]

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!

[DrByte]

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.

[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

[Limitless]

Sorry OP, No help, just commiserating...

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

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

[DrByte]

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.');

2. /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');

3. 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;
          }
        }
        
        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;
          }
        }
        
      }

[Limitless]

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.

[DrByte]

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?

[Limitless]

Authorize.Net: http://www.authorize.net/solutions/m...urringbilling/
Paypal: https://www.paypal.com/cgi-bin/websc...erview-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.

[ZoftheAshes]

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