I've got in touch with cURL these day, and I must say: it isn't really problem to emulate a webbrowser with.
So I started thinking what cool things I could do with this system and I though it'd be possible (it's possible, 100%) to make a sort of your own interface to those systems.
Now the question is: What would the guys from PayPal etc. think about? Or would it even be illegal? In fact: why? I'd be doing exactly the same thing as the user does.

Any opinions?
Greg

I don't think it's ok or legal. And I bet they have to log the IP address for each transaction made and therefore that would always point to your box...

Although a little off topic I have recently implemented Paypal support into my systems and PayPal notification handlers ( callback ) are indeed handled with cURL - but this way: your callback page gets called then you call Paypal back using cURL and get a status code.

This was my first encounter with cURL and I also think it's really cool

Well about the legal thing... why should they care? Their servers would do exactly the same thing (even less, because you don't need to load their sign up page), they would get exactly the same information trough their SSL-Server etc.
The only thing'd change would be that the hoster can easier integrate the system in his database!

Maybe we could get a statement from PayPal or 2Checkout directly. I didn't maild them, because it takes them always like a week to get a reply...

Excuse my english, still learning :)

This opens up for a lot of fraud. You ( the host ) could easily store the CC number ( this thing alone I would say is a reason they don't allow it - security risk ).

You could also then call the 2checkout script via cURL pretty much anytime you'd like using a fake/your own email for order notifications.

A guy from 2checkout.com sometimes drops in here and answers questions, hopefully he will clarify this.

To be honest, if 2checkout says it is ok I would stop using them. The process of getting a real merchant account is somewhat strict for a reason - I mean there is a responsibility to handle CC numbers.

When I understeand the following post (http://www.phpbuilder.com/forum/read.php3?num=2&id=168380&thread=125757) at phpbuilder.com, PayPal seems to accept it!

Well they talk about IPN and that's what I talked about in my first post in this thread. That's only the callback handling after a successful transaction has been made.

ahh ok, thank you! I think then the same thing'd possible for reve and 2check like you said.

Well that's life ;)

Yes, that's too bad. Great idea and I have been thinking about these solutions myself. Since I am non-US based a real merchant account would cost me way to much, therefore I am with 2checkout, but I would sure want the functionality a real merchant account can give

Credit card companies prohibit anyone from storing some of their credit card data (e.g. C.V.V.s).

Any site discovered doing this would certainly almost immediately lose thier merchant account. Not a concern for anyone using third-party processing, admittedly, but why would a third-party processor permit one of their customers to place their account at risk?

We would lose a valuable resource regarding "proof of sale" if IPs were all generated from the merchant. In the event of a dispute or chargeback we regularly pull IP information. This counts as a "signature" of sorts.

Everyone wants to cut down on the amount of fraud seen through Internet transactions. We'd hope that anyone doing business online would certainly want to reduce the chance of more stolen credit card information floating around the 'net and to provide processors with as much information to identify fraud as possible.

check this link out, and look at the second routine (Authorize.net):

http://www.2checkout.com/cart_specs.htm

From what I understand, you can simply collect everything from the client (including CC#) and send it to a specific CGI program on their server (using cURL or something to post it in a secure manner).

You can do the same thing with SWREG.org, I wrote a post before about it, but as of March, they are going to have some changes and their service is gowing to be like this:

- 20$ / month fees
- 4% + 1$ transaction fees with 1.5$ minimum + 2% extra for AMEX
- free international repayment (that really matters to me coz wire transfers cost ~ 35$ each time!!).

the changes aren't finalized yet, they are being discussed now.

I must also note that according the 2checkout's support, they are negotiating the possibility of giving debit cards to their international customers with MasterCard. These can be used in any ATM machine with the MasterCard logo to withdraw money, making international payments free of charge!

Originally posted by kdach
Credit card companies prohibit anyone from storing some of their credit card data (e.g. C.V.V.s).

Any site discovered doing this would certainly almost immediately lose thier merchant account. Not a concern for anyone using third-party processing, admittedly, but why would a third-party processor permit one of their customers to place their account at risk?

* Do you mean that it isn't ok even for you to store CC#'s?
- How do you handle recurrent billing?
- How come Amazon.com can store my CC#'s? ;)


We would lose a valuable resource regarding "proof of sale" if IPs were all generated from the merchant. In the event of a dispute or chargeback we regularly pull IP information. This counts as a "signature" of sorts.


According to your website:

x_Card_Num - You must have an SSL server to send the credit card # in. If you do not, a warning will be printed letting the buyer know that their credit card number was transmitted over and insecure channel.


* If that means that it is our website who is posting the data ..
- How would you know the original users IP address?
(maybe we should send it as a parameter?)

* If it means that the user will be redirected from our website to yours ..
- How would you know if the information was sent to our website over a secure connection or not?
(maybe by checking the HTTP_REFERER?)



Everyone wants to cut down on the amount of fraud seen through Internet transactions. We'd hope that anyone doing business online would certainly want to reduce the chance of more stolen credit card information floating around the 'net and to provide processors with as much information to identify fraud as possible.


Thanks alot for the great service :)

Going to try to convince the owner/president to author a definitive answer for everyone regarding cURL interfacing.

C.V.V. codes were the credit card industry's "answer" to fraud - I stated that "some" credit card information wasn't permitted to be stored. Recurring billing requires a merging of data sources -- complete credit card information is not stored anywhere on our server.

And a bit OT (perhaps):

Everyone imagines that a lot of things are possible with their own merchant account. I suggest reading (including the fine print) a complete Merchant Account Agreement. While it is true that there is more flexibility, my favorite question (most frequently to webhosters) is WHY they would want to handle transactions a specific way.

Most notably, the Sales Dept is frequently asked if a previous sale has to be voided when a customer wants to upgrade a hosting plan. Not technically, no. But why wouldn't you want a record of the new transaction on file for the sake of spending a minute or two cancelling their current order? If you've been a good service provider and you have what the customer is looking for they certainly shouldn't argue about placing their new order.

I often wonder exactly what people are looking for when they mention "flexibility". Shortcutting good business practices tends to cost a lot more in time and money in the long run.

Back OT: I hope to have a response for you all within a day or two.

:)

Originally posted by kdach
I often wonder exactly what people are looking for when they mention "flexibility". Shortcutting good business practices tends to cost a lot more in time and money in the long run.


well, consider ..

1) Customizable plans, people can make up their own plans
2) Integrating a more advanced (complex) discount system ..
3) Integrating a more complex shipment costs calculator ..
4) Integrating a refferer discount ..

And a lot more :)

Besides, the sales department won't be able to make special deals for specific customers, the plans are fixed in the system, unless they make a new plan for each customer, and that will make management hard.

Consider a development/design company, that take a project and give a quote to the customer, what would that interpret to in the payment system? it is not a fixed price product.

Thanks again :)

mind the "lots of questions", just doing my homework ;)

Originally posted by ahmadhash
well, consider ..

1) Customizable plans, people can make up their own plans
2) Integrating a more advanced (complex) discount system ..
3) Integrating a more complex shipment costs calculator ..
4) Integrating a refferer discount ..I believe you can do most, if not all, of this using the current 2CheckOut system. The 2CheckOut shopping cart interface lets you do this. After you figure out the final cost you can give 2CheckOut the amount and any name/address/phone info you collected so the customer doesn't have to enter it twice. The only drawback is the 2CheckOut cart interface doesn't (correct me if I'm wrong) have an option for recurring payments.

2CheckOut -- any plans to add a set of variables to the cart routine to mark a transaction as recurring (monthly, yearly, every X days, etc) so custom recurring charges could be easily used with your system?

-Jeff

So, I have a question about: http://www.2checkout.com/cart_specs.htm
Does it mean I can have the subscribe form on my site and the user will be redirected to yours just for putting in the cc info and then he gets back to my site?

The only drawback is the 2CheckOut cart interface doesn't (correct me if I'm wrong) have an option for recurring payments.

Well this only drawback is the thing that make us think in these terms



Originally posted by jffmrk
2CheckOut -- any plans to add a set of variables to the cart routine to mark a transaction as recurring (monthly, yearly, every X days, etc) so custom recurring charges could be easily used with your system?

-Jeff

Actually what I am looking for is the flexibility to have such a variable not per transaction but per product. I want my customers to be able to mix recurring and non-recurring products in their shopping cart

For example:

1. Webhosting Plan A: $10 setup, $12 montlhy

2. 100 extra MB of disk space: $0 setup, $30 annually

3. Installation of software X: $30 onetime


For now my customers need to
1. Sign up for webhosting on my site. Being transferred to 2checkout and then enter all cc info etc and after successful transaction go back to my order page where they

2. Sign up for 100 MB extra disk . Being transferred to 2checkout and then AGAIN enter all cc info etc and after successful transaction go back to my order page where they

3. Now can use the regular 2ckeckout shopping cart to add the 30$ onetime product, being transferred to 2checkout and then AGAIN enter all cc info etc and after successful transaction they can now take the next bus to the doctor to get their hurting hands treated

See my point?

Isn't that possible to be done easier with a real merchant account? That's the kind of flexibility we want from you and 2checkout, kdach :)

All this cURL stuff is only us trying to find a way around this.

I must add I am very pleased with 2checkout, and even more when their people come here to this forum answering questions, just checking if it is possible for you to consider futher enhancing your great product?

Originally posted by Schumi3
So, I have a question about: http://www.2checkout.com/cart_specs.htm
Does it mean I can have the subscribe form on my site and the user will be redirected to yours just for putting in the cc info and then he gets back to my site?


Yes.

[/B] if it is possible for you to consider futher enhancing your great product? [/B][/QUOTE]

We're are always considering further enhancement - some, obviously, aren't always visible or immediately noticed by our merchant vendors.

The list of things our programmers have to augment or add for 2002 seems endless at times. They work diligently on day-to-day matters as well as find time to add new processes.

When we look at what the site was in Jan 2001 compared to what it is now we are all pretty happy -- but never happy enough to stop trying to improve what we have to offer.

I can only counsel patience and repeated reminders both directly to support@2checkout.com and on sites like this one. If the demand is great enough it tends to bump projects up on our to-do list.

Thanks,

Originally posted by ahmadhash
I must also note that according the 2checkout's support, they are negotiating the possibility of giving debit cards to their international customers with MasterCard. These can be used in any ATM machine with the MasterCard logo to withdraw money, making international payments free of charge!

I would really love to see this feature.