How to validate form data when I don't have access to the processing file?

[artdyke]

So I'm launching a paysite soon and we're using a 3rd party payment processor. However, said 3rd party is more geared towards maintaining htaccess username/password lists rather than working with a database. After running some tests, I found that the 3rd party isn't running any kind of validation to check if the user already exists and I'm able to sign up with duplicate emails/usernames. So I need to do some validation myself.

 

I'm used to keeping the form, validation, and processing all in the same file. How can I do the form/validation on my side and then send the POST stuff to the final processing file once it's validated? It seems like I would need two "action" destinations... my own validation one and then if that clears, on to the 3rd party one. How do I do that? This seems like it would be easy but I haven't been able to figure it out...

[Psycho]

Validate the data, then resend it to the final URL via POST. Here is an article/tutorial/. I have not read it so I can't guarantee anything

 

http://wezfurlong.org/blog/2006/nov/http-post-from-php-without-curl/

 

EDIT: You might also want to check out this page in the PHP manual:

 

http://www.php.net/manual/en/context.http.php

[dcro2]

How exactly does the process for payment work? Does the browser need to go through several pages after submitting your form?

[artdyke]

Yes, it takes you to the 3rd party site to go through several steps.

[dcro2]

Then.. what you could do is:

1. Make the form submit to your own .php validator

2. If everything checks out, output a form with all hidden fields containing the same data that was submitted, with the action set to the payment processor page.

3. Include some javascript in the page to submit the form automatically. Include a visible submit button in case Javascript isn't enabled.

 

Unfortunately, that means it's possible to modify the form before submitting. But unless you can output all the html returned by the payment processor and not have any problems with cookies, and all images/forms still work, then I can't think of another option. Unless you want to take on handling transactions between your visitor and your payment processor by yourself.

[artdyke]

Looking at the above links from mjdamato, are there any advantages/disadvantages to the cURL method vs. the HTTP POST method described?

[xyph]

cURL keeps everything server-side. It won't allow the client to modify the requests. It's the only secure way to do this.

 

If there's no validation on the 3rd party side, are you sure you want to use this provider? The only way you can be sure that X user on your site is actually linked to X user on the 3rd party side if they send you a unique userid after creating an account. If the only way you can process a transaction is by a field that may have duplicates on the other end, then you can't be sure who you're actually charging.

[dcro2]

cURL keeps everything server-side. It won't allow the client to modify the requests. It's the only secure way to do this.

 

If there's no validation on the 3rd party side, are you sure you want to use this provider? The only way you can be sure that X user on your site is actually linked to X user on the 3rd party side if they send you a unique userid after creating an account. If the only way you can process a transaction is by a field that may have duplicates on the other end, then you can't be sure who you're actually charging.

But that means the OP has to go through all the steps of the 3rd party processor with cURL, passing back forms, errors, etc back to the browser. Which is doable, but could be complex.

 

Just to make sure, can you name your payment processor? Maybe they have some API you don't know about?

[artdyke]

It's Zombaio, who we must use for a number of reasons. I assume they do their own validation on their side, but it needs to match up with my database on my side, hence the need for validation on my side.

 

What I really need to know is if there is a way to make cURL behave just like a regular POST form, redirect and all. I've found several threads around with questions along these lines but they've never been answered once it gets down to the basic question of how to redirect the user along with the POST data. Is this not possible?

[xyph]

Simply based on their website, I would not trust them with my own credit card, let alone my clients. If they can't get HTML right, how the hell can they get online transactions right.

 

That aside, https://www.zombaio.com/developer_sdk.asp may help you find what you're looking for.

[dcro2]

Then.. what you could do is:

1. Make the form submit to your own .php validator

2. If everything checks out, output a form with all hidden fields containing the same data that was submitted, with the action set to the payment processor page.

3. Include some javascript in the page to submit the form automatically. Include a visible submit button in case Javascript isn't enabled.

 

Unfortunately, that means it's possible to modify the form before submitting. But unless you can output all the html returned by the payment processor and not have any problems with cookies, and all images/forms still work, then I can't think of another option. Unless you want to take on handling transactions between your visitor and your payment processor by yourself.

That's pretty much the only way to "redirect" with POST data, unfortunately. But they have an option to send your data through GET instead of POST, so you can redirect to that url instead. See page 16 of their API documentation. On page 17 there's also something that might be a way to send all your data including credit card number to the processor without leaving your site, but I'd be weary of doing that if your site has no SSL.

 

Here's the most important part from the PDF:

Using HTTP GET instead of HTTP POST

Page 16 (36) Version 2.13

Some platforms prefer to use HTTP GET instead of HTTP POST when sending data to our join forms. Our examples above shows the use of the embedded http post method, but the http get methos are supported through our http get proxy script.

To use HTTP GET for subscription billings, send data to:

https://secure.zombaio.com/get_proxy.asp

To use HTTP GET for purchase of credits, send data to:

https://secure.zombaio.com/get_proxy_credits.asp

Example:

https://secure.zombaio.com/get_proxy.asp?SiteID=287648953&PricingID=931053&Cro ssSale_Offer1=938445&return_url_decline=www.test.com

[artdyke]

Yeah, they're a little wonky in places, but I know a lot of people that use them and they have a flawless reputation.

 

I'm about to switch to GET and see if I can figure that one out. Security's not really an issue since I only have to validate username/email on my end. Otherwise I'll do the hidden form method. I was just hoping there was a slightly more elegant solution out there.

[xyph]

There is, but it would take quite a bit of testing and prodding to get it working.

 

You could use file_get_contents( get url here ) and parse what's returned, assuming you get a different result for a positive or negetive response.