Building a Store Credit System

[burt]

@@clustersolutions what happens if the credit balance covers the full cost of the order, therefore bringing the total cost to zero.

[clustersolutions]

@@burt...this post covers your question...

 

http://www.oscommerce.com/forums/topic/407420-ccgv-help/?p=1726370

 

Basically, hide/remove etc. the payment module at confirmation, and at checkout_process unset the $payment and any requirements to have an actual payment. Also, some logic is needed to set the payment method to store credit. The checkout pages were heavily hacked...

 

Currently, the CCGV is frankenOOP and a lot of the properties are set in the global session variables...for sure, a redesign CCGV and shipping using OOP would be a lot better in handle issue that I was discussing above to eliminate chicken and egg problem from a procedural point of view...well, I have a finished thesis but not a good one...

[MrPhil]

Could there be instances where a store credit would cover the entire payment due, but a customer might reasonably not want to apply the full credit at this time (just part of it)? Automatically applying the full credit might also leave a tiny balance due that isn't worth charging a credit card for, so the customer might want the option of applying just part of the credit.

 

Also be aware that many legal jurisdictions may require that you pay interest on customer credit balances, so you may need a mechanism for periodically adding to the balance. Finally, a customer may decide at any time to have you send them a check/cheque or credit their card for the credit balance, so have procedures in place for that.

[clustersolutions]

I thought of your first point way back, but it was just easier to go with the all or nothing approach. This would be "over thinking" it...our credit system has been in place for 8 years now and we have not one request to apply a partial credit. Perhaps we use our credit system mostly for exchanges. I am very sure that this could be easily accomplished should there was a requirement.

 

As for your second point, it falls within your store policy as well as by law. Our store policy store credit is good for up to one year but we never enforce it unless your a real bad customer!!! I sometime wonder since by tax law in the U.S. we are required to keep receipts and records for up to three years so what would happen if I would just keep the money after three year? But that hasn't happened yet. For the second point here, I think it would be too much to ask for a shopping cart to do. That was the reason I said we had a liability account in our accounting system to handle that. It shows a snapshot of our credit liability for tax and accounting purposes. Should I was required to pay interest, I would just setup a recurring transaction in my book to pay those interests. Customer do request converting a store credit to payment, we do do that by removing the store credit in OSC, and then issuing the payment in our accounting system and that amount would be deducted from the credit liability account. Now depending on how long its been since the store credit was issued, for most of the time we ended up cutting a check instead of refunding through the CC.

 

Again, I am a true believer in using the right tool for the right job...I use/integrated sql-ledger for over 10 years now. Lastly, CCVG although being a core code hacker, the work flow it has in place does allow you to automate credit deposit into customer's account as cash back reward, fb like gate reward and etc...well fb like gate's done now but it did its job in getting fb customers...

 

 

 

Could there be instances where a store credit would cover the entire payment due, but a customer might reasonably not want to apply the full credit at this time (just part of it)? Automatically applying the full credit might also leave a tiny balance due that isn't worth charging a credit card for, so the customer might want the option of applying just part of the credit.

 

Also be aware that many legal jurisdictions may require that you pay interest on customer credit balances, so you may need a mechanism for periodically adding to the balance. Finally, a customer may decide at any time to have you send them a check/cheque or credit their card for the credit balance, so have procedures in place for that.

[discxpress]

@@burt

 

If the credit covers the full cost of the order, disable all available payment methods. Of course you know I'm not a coder, so I don't know if that could be accomplished without hacking the core code. If the credit covers part of the balance, leave the payment methods available and pass the discount to the payment modules like Paypal, Braintree or Stripe(which I use).

 

I do think this is a perfect opportunity to create a discount module as well. A two in one. There's one question. Should the customer be allowed to use the store credit and discount together? I think not.

 

Just my thoughts

[burt]

As of this moment, the system goes like this:

 

Admin Side:

 

1.  customers.php (core code changes)

- addition of extra input box to hold "credit value".

- addition of logic to process this when press the update button

 

2.  customers.php language file

- addition of a couple of text bits for display in the customers file

 

Shop Side:

 

Far more complicated...

 

1.  Creation of Credit Class

- dropped into the classes folder

 

2.  Call the class in application_top.php

- core code change to add the call

 

3.  New CM module to show in account.php

- this displays how much credit the customer has available

 

4.  New "fake" payment module.

 

5.  New Order Total module

- for applying the store credit

 

6.  Hook in checkout_payment

- if the value of the credit exceeds the order_total, this hook does the following;

-- invokes the new "fake" payment module

-- redirects to checkout_confirmation

 

7.  Hook in shopping_cart class file

- this hook reduces the available credit appropriately when $cart->reset happens in checkout_process

 

To Do (possibly):

 

A, Content Module for Checkout Success, showing reduced Credit Balance (of course this reduced balance already shows in account.php)

B, Hook in header.php, to invoke the messageStack - which would show available Credit Balance (would show when customer_is_logged_in AND cart_contents > 0 AND php_self != checkout pages)

 

All in all, a simple system to do a simple and specific task with Minimal Core Code changes.

[MrPhil]

I thought of your first point way back, but it was just easier to go with the all or nothing approach.

Looking at it from the customer point of view, the more flexibility they have in determining how to spend their credit, the happier they'll be with you. Sure, it's easier to do the simplest thing, but there are advantages to doing harder things.

 

As for your second point, it falls within your store policy as well as by law. Our store policy store credit is good for up to one year but we never enforce it unless your a real bad customer!!! I sometime wonder since by tax law in the U.S. we are required to keep receipts and records for up to three years so what would happen if I would just keep the money after three year? But that hasn't happened yet. For the second point here,

Be careful there! A credit balance is usually legally a debt owed to the customer, that needs to be tracked indefinitely until used, refunded, or discharged by bankruptcy. It's easy for a customer to forget that they have a small credit amount. At some point, you may be required by law to report or even turn over such a balance to the state's abandoned property agency, or to remind the customer yourself. I think it would be advantageous to remind the customer every 6 to 12 months. It's more likely that they will choose to make a purchase, possibly spending extra money, rather than going through the bother of getting a check cut or a credit card chargeback. It's free advertising for you, and not subject to anti-spam regulations. Anyway, remember that they own that money, not you!

[clustersolutions]

@@burt, I am looking forward to learn these hooks and apply them...

 

Is step 4 fake payment module necessary?

 

A step may be missing on when the customer select to apply the credit. This a a crucial step that will dictate the codes. A lot of work was necessary for me to simplify the checkout process to two pages and allow the customer to apply the credit during confirmation as it make sense for that step to be there. The original CCGV ask the customer to enter it (I think) in the checkout_shipping/payment page and I found that it was better to group all the payment/billing stuffs on a single page...my $0.02.

 

 

 

As of this moment, the system goes like this:

 

Admin Side:

 

1.  customers.php (core code changes)

- addition of extra input box to hold "credit value".

- addition of logic to process this when press the update button

 

2.  customers.php language file

- addition of a couple of text bits for display in the customers file

 

Shop Side:

 

Far more complicated...

 

1.  Creation of Credit Class

- dropped into the classes folder

 

2.  Call the class in application_top.php

- core code change to add the call

 

3.  New CM module to show in account.php

- this displays how much credit the customer has available

 

4.  New "fake" payment module.

 

5.  New Order Total module

- for applying the store credit

 

6.  Hook in checkout_payment

- if the value of the credit exceeds the order_total, this hook does the following;

-- invokes the new "fake" payment module

-- redirects to checkout_confirmation

 

7.  Hook in shopping_cart class file

- this hook reduces the available credit appropriately when $cart->reset happens in checkout_process

 

To Do (possibly):

 

A, Content Module for Checkout Success, showing reduced Credit Balance (of course this reduced balance already shows in account.php)

B, Hook in header.php, to invoke the messageStack - which would show available Credit Balance (would show when customer_is_logged_in AND cart_contents > 0 AND php_self != checkout pages)

 

All in all, a simple system to do a simple and specific task with Minimal Core Code changes.

[clustersolutions]

Well...definitely another point of view. My experience trend to tell me to limit good options to customer to increase conversion, and doing things the hard way wasn't always better. I ran massive computational programing to learn that a simple stochastic analysis may produce the same outcome.

 

Yep, that's why I stress good "audit trail" and I leave the rest to my accountant. You know I think I still have my Cheese Cake Factory gift card from 10 years ago I wonder if I should still collect...and my VISA gift card had never pay me interest. In fact, I had a Pepboy gift card that still had $10 on it and it expired...damn people...

 

 

Looking at it from the customer point of view, the more flexibility they have in determining how to spend their credit, the happier they'll be with you. Sure, it's easier to do the simplest thing, but there are advantages to doing harder things.
 

Be careful there! A credit balance is usually legally a debt owed to the customer, that needs to be tracked indefinitely until used, refunded, or discharged by bankruptcy. It's easy for a customer to forget that they have a small credit amount. At some point, you may be required by law to report or even turn over such a balance to the state's abandoned property agency, or to remind the customer yourself. I think it would be advantageous to remind the customer every 6 to 12 months. It's more likely that they will choose to make a purchase, possibly spending extra money, rather than going through the bother of getting a check cut or a credit card chargeback. It's free advertising for you, and not subject to anti-spam regulations. Anyway, remember that they own that money, not you!

[burt]

@@burt, I am looking forward to learn these hooks and apply them...

 

Is step 4 fake payment module necessary?

 

A step may be missing on when the customer select to apply the credit. This a a crucial step that will dictate the codes. A lot of work was necessary for me to simplify the checkout process to two pages and allow the customer to apply the credit during confirmation as it make sense for that step to be there. The original CCGV ask the customer to enter it (I think) in the checkout_shipping/payment page and I found that it was better to group all the payment/billing stuffs on a single page...my $0.02.

 

No need for any customer input here, the credit is always applied regardless to the very limit of the credit balance...up to the value of the order_total or the credit balance whichever is the lowest amount.

[clustersolutions]

Gotcha...yeah, never had a customer who didn't want to apply the credit ASAP...KISS

 

No need for any customer input here, the credit is always applied regardless to the very limit of the credit balance...up to the value of the order_total or the credit balance whichever is the lowest amount.

[MrPhil]

Well, it can vary among legal jurisdictions. If you want to take that money if they don't use it within a certain period, I think you can charge a periodic fee on it, so long as it's clearly spelled out. I remember once being given an Amex gift card, and didn't try using it for nearly a year. By that time, about 80% or so had been taken in fees! Whatever is allowed by law, you should clearly spell out in the T&Cs, and perhaps remind the customer at the time they bank the balance. You don't want to confiscate a non-trivial balance and then have the customer come after you in court. Just sayin'... If you really want to get into a formal store credit program (as well as gift cards, etc.), I would get some good legal advice regarding the laws that apply to your business. Finally, converting a credit balance into a sale (often with more money being supplied) probably makes both you and the customer happy, so that's the way to go. I would never give an Amex gift card, and if I ever receive another, I'll spend it within days!

[Mort-lemur]

Paypal gift vouchers bought against your store go into a "pending" status on your paypal balance - and they do not have an expiry they last forever until used

[burt]

What happens if a customer wishes to use his "paypal gift voucher" and pay the rest (eg) "check/cheque".

Possible? 

[Mort-lemur]

@@burt Not possible - they have to complete the whole transaction via paypal

[burt]

Hmmm.  Then I guess it is considered payment credit if they choose to pay by Paypal.  It's not Store Credit exactly.

[Mort-lemur]

Yes - I was really responding to MrPhil about expiry, charges etc I know it wouldnt sit well with a store credit system

[burt]

Ahh, ok.  

[burt]

Update on this, it is 99.9% finalised.

 

Shopper can see his available credit in account.php:

 

http://oi57.tinypic.com/2qcqs83.jpg

 

Now the shopper can select to use the Store Credit or not in checkout_payment.php:

 

http://oi61.tinypic.com/2uoi69d.jpg

 

If the shopper has no Store Credit available, this tickbox does not show, in which case, the checkout progresses as normal.

 

The Magic

 

At this point, the shopper can do one of two things;

 

1.  The shopper does not tick the "use credit" box

In this case ... the checkout progresses as normal.

 

OR

 

2.  The shopper ticks the "use credit" ... in this case ... 3 things happen;

2a. Order Total Module is invoked which reduces the amount payable appropriately

2b. Depending on the "amount to pay" the chosen Payment Method will be changed to "Store Credit".  Paypal et al cannot deal with a zero cost order.

2c. After the checkout is complete, the shoppers credit balance is reduced appropriately.

[greasemonkey]

Nice... Wondering how/if I could use this to replace my stupid gift card mod.

[pouncepony]

Any status update on this? I have this exact requirement.

 

Thanks

[burt]

Update;  The shopowner for whom this was built wanted an extra face to this;

 

Existing:  

Admin Side;  way to attach a voucher amount to a customer

Shop Side;  a logged in customer (who has a credit balance) can useit to pay all of or part of the cost of the order.

 

 

What the shopowner wanted as an extension;

Admin Side; set up a system to allow him to create a voucher code, with an amount attached (eg: abc123 is worth $50, def999 is worth $100)

Shop Side; set up a system to allow logged in customers to input a voucher code, that amount is then added to their credit balance ready for use, and the voucher becomes deactivated.

 

 

Can anyone see a real life use?

 

Shop owner can now sell "gift cards".  When one is sold, he manually creates a voucher to the same amount, and lets the customer know the voucher code.  That customer can now give the voucher code as a Xmas present to someone else.

 

 

And so, yes it is a manual process to go from the sale of a "voucher" to a useable voucher code...but that's what this shopowner required.

 

 

Core Changes for the extension;

 

Zero.

 

Admin Side:  New Voucher adding/editing/deleting page

Shop Side:  New link in account.php (got a voucher, redeem it).  The redeem link to a submodule which allows to input voucher code, and if the code is "good" credit balance is added to that customers account.

[zeppo]

I'm also in the need of a Credit system which will be used in conjunction with an invite system so customers can earn credit by inviting friends and then use this credit for shopping. What's the status atm, can I help?

[freakystreak]

Was this ever completed and added as a contribution?

[burt]

It was completed.

It was not added as a contribution.