Member Subscription Help

Hi,

I’ve read the posts about the different member subscription programs WebAuth, OpenCrypt, and aMember but had some questions about them.

The personal trainer that I’m doing a site for wants to offer his services via a web format like Jillian form Biggest Loser. He also has clients that he takes care of locally. From reading about the different services, it sounds like all 3 programs would take care of the web based members. I especially liked OpenCrypt where a user can easily send a message (something my client really wants).

The most important thing he wants users to be able to do is log in and build a meal plan daily. The meal plan would be built using MySQL and allow users to pick proteins, veggies, etc. then write a file on a daily basis. I’m just not seeing how I could integrate the 2 databases. He wants to be able to log in and see what people have added if need be. It seems like OpenCrypt might be the better choice judging from features. Do you have access to the user DB if one wanted to link them? I was thinking that the meal plans would be related to the user.

I hope this all makes sense. Thanks for any help.


dynamo mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

If you want to implement a “single sign on” system, where people can log in, and then see information customized to them, you are going to need to implement your login and your data publishing system as one integrated solution. I’m not familiar with any of these systems you note here, but if any of them are installed on your server as PHP code, you could possibly hack them up to add the fields you need to hold the personal menu information.

My own preference would be to build my own system from scratch, implementing the login and the personalization as a single database with multiple views.

Walter


dynamo mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Hi Walter,

I was wondering the same thing. These programs (or scripts) make it easy to do payments and that and since I’m a novice at this, I thought it would be a huge time saver. With what I’ve learned since you helped me get PHP and MySQL running on my computer, I’m confident I can do the login and meal plan part. I’m not as confident about taking payments. I want to set it up to be easy so if the trainer ends up being really successful especially with the online training program, it is easy for him to take payments. Right now he only has local clients and takes checks.

Thanks again for your help.

Brian


dynamo mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Taking payments usually consists of being able to send a secure POST to another server. I usually trick the browser into doing that for me by setting up (programmatically) a form consisting of hidden elements with all the data I’ve already gathered (name, address, e-mail, etc.) and a single submit button. Then I rig that form to auto-submit as soon as it loads. If the person has JavaScript disabled for whatever reason, then they see the button and push it and off they go.

The payment gateway then shows their screens to the customer, and you never ever see the credit card numbers or anything. Sleep well, knowing less!

Most payment gateways then want to send you a POST back with the results of the payment process. Figuring out the result of that is as simple as processing a POST from your own server, and the gateway will give you a little cheat sheet of all the possible responses and what they mean.

I have built many stores, so your mileage may vary, but once you get past the basics of handling a form and saving fields in a database, connecting to a payment gateway is not that hard.

Now if anyone tells you that you have to do business using HSBC – run, run screaming! I just spent most of a month doing a one-week job utilizing that particular box of hammers. I will write that up some day so that nobody has to suffer as I did.

Walter


dynamo mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Sometime around 27/5/08 (at 18:39 -0400) waltd said:

I usually trick the browser into doing that for me by setting up
(programmatically) a form consisting of hidden elements with all the
data I’ve already gathered (name, address, e-mail, etc.)

Clever! Out of interest, as I’ve wondered about this (but never
tested it), can hidden fields be populated automatically by a user’s
browser? If so, that’s quite a security risk.

Not that this is what you’re doing or why you’re doing it, but if it
is possible to make a page that automatically grabs the user’s
‘auto-enter stored’ email address and other details and sends it
somewhere without the user being aware of it…

k


dynamo mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Thanks for the vote of confidence. I guess one of the things that really scares me about doing it on my own is the fact that security is so important-I don’t want to be responsible for card info!

Are there any resources that you feel are particularly good? I have the Welling and Thomson book as well as the From Dummies book by Valade. They both talk a little about setting up stores but don’t go into this type of thing-more of a subscription based.

I liked the idea with the other programs/scripts that payments would auto-renew. If the trainer had to do some work-like maybe clicking a button that would search for who needs to renew, that would probably be ok. Again, I’m trying to think of the future and want to make it easy for him to process payments.

Thanks again for your help.

Brian

On 27 May 2008, 10:39 pm, waltd wrote:

I have built many stores, so your mileage may vary, but once you get past the basics of handling a form and saving fields in a database, connecting to a payment gateway is not that hard.

Now if anyone tells you that you have to do business using HSBC – run, run screaming! I just spent most of a month doing a one-week job utilizing that particular box of hammers. I will write that up some day so that nobody has to suffer as I did.


dynamo mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

On May 28, 2008, at 4:23 AM, Keith Martin wrote:

Sometime around 27/5/08 (at 18:39 -0400) waltd said:

I usually trick the browser into doing that for me by setting up
(programmatically) a form consisting of hidden elements with all the
data I’ve already gathered (name, address, e-mail, etc.)

Clever! Out of interest, as I’ve wondered about this (but never
tested it), can hidden fields be populated automatically by a user’s
browser? If so, that’s quite a security risk.

Not that this is what you’re doing or why you’re doing it, but if it
is possible to make a page that automatically grabs the user’s
‘auto-enter stored’ email address and other details and sends it
somewhere without the user being aware of it…

No, and no! Thank goodness!

What I meant here by programmatically is if you want to send someone
off to https://bigbank.com/paymentgateway with a POST full of useful
data in tow, you first send them within your site to a page like
http://yoursite.com/store/payment/123

Inside your application, the server picks out order number 123 from
the database, re-hydrates it with all the known information about
that order, and makes up a form page that looks like this:

<form action="https://bigbank.com/paymentgateway" method="post">
<input type="hidden" name="name" value="<?=$order->h('name')?>" />
//lots of other fields, like how much, in what currency, et cetera
<input type="submit" value="Enter Payment Information" />
</form>

And then that page has an onload to submit the form, like
onload="document.forms[0].submit();" which makes it submit as soon
as it has loaded, unless JS is off for some inane reason.

This way, you don’t have to break out cURL, figure out how to send a
secure POST, figure out that the bank really wants to see a
particular browser string or two in your POST, reverse engineer the
entire HTTPS protocol – all that stuff that the browser mfrs have
already wasted entire cases of Jolt figuring out for themselves.

I have tried to get autofill to do the bad thing before, just to see
if it would happen. It didn’t, at least in any of the browsers I
tried. There is something quite different event-wise when JavaScript
enters a field and “presses” tab than when you or I do the same thing
with a mouse and a keyboard.

Walter


dynamo mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

On 28 May 2008, 2:19 pm, Brisprad wrote:

Thanks for the vote of confidence. I guess one of the things that really scares me about doing it on my own is the fact that security is so important-I don’t want to be responsible for card info!

Don’t worry. The responsible folks at the bank will steer you well clear of that part. Now you do mention that you want to do recurring (subscription) billing. So that’s a different matter. More about that in a moment.

Are there any resources that you feel are particularly good? I have the Welling and Thomson book as well as the From Dummies book by Valade. They both talk a little about setting up stores but don’t go into this type of thing-more of a subscription based.

The Welling and Thomson book is the one I always recommend. I personally started off with a truly awful WROX book that was like a sheer vertical climb wearing roller skates. Reading W & T was such a relief after that. I have a couple of others, the SitePoint Anthology and a couple of advanced PHP5 books from some other publisher I can’t recall off-hand. They’re each good for some part of the puzzle. But the Google is still the best source in my experience.

I liked the idea with the other programs/scripts that payments would auto-renew. If the trainer had to do some work-like maybe clicking a button that would search for who needs to renew, that would probably be ok. Again, I’m trying to think of the future and want to make it easy for him to process payments.

You might want to talk to your payment gateway people about this part of the issue. Perhaps there is a way where you can store a hashed value of the card number in your database – basically a unique identifying code that stands in for the real credit card data. And then you can automatically send a renewal request through without the need to store the actual credit card information in your server. That would be a scary thing.

Walter


dynamo mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options