After submission from http://chris.green2sustainable.com/sign-up,
https://sdashchris.chargevault.com//update?key=927f5fb7b1&code=...
displays the text:
Chris Sustainability Dashboard
Hi, c!
You are currently subscribed to the GREEN_PLAN plan.
A payment method is not available for your subscription. Add a Method of Payment
Your next invoice is scheduled to be billed on December 16th, 2011.
One of yoru FAQs says "SIgnup for a free CheddarGetter account. By default, your account will be in gateway simulation mode. " but I thought I did this. Is something more required to test hosted credit card submission on my chris test server w/o paying for a real billing solution setup for this server?
#1 Posted by Marc Guyer Support staff on 18 Nov, 2011 10:03 PM
When the customer was created, no payment information was sent, so there's no billing information for the customer. This is expected behavior.
https://cheddargetter.com/admin/customers/get/code/205e19721b2045cd...
Your account is in gateway simulation mode.
#2 Posted by chaynes on 18 Nov, 2011 10:35 PM
So if I create the account w/o payment info, I can't use update to add payment info?
We want first to use our system to collect client info other than payment info, and that's working. Then use your hosted payments page to add payment info, but the hosted payment page then doesn't provide for entering payment info.
And should it be possible to test all this in gateway simulation mode?
Thanks again for your help.
#3 Posted by Marc Guyer Support staff on 19 Nov, 2011 01:10 PM
Hi Chris -- It looks like you may have found an obscure bug there. I was able to replicate it with an account with only one pricing plan configured:
I was unable to replicate this when more than one pricing plan was configured. So, it seams that the workaround for now is to configure a second pricing plan in your dev account.
We'll endeavor to get that fixed. Thanks for bringing it to our attention!
#4 Posted by chaynes on 28 Nov, 2011 06:29 PM
Ok, the workaround works.
Now the problem is that Referer redirection doesn't work. (The reason it really needs to is we have to check if they have changed their contact email address, as we don't allow that at present, and there doesn't seem to be a way of keeping that off your hosted info form).
Here's what the hosted redirect is (and it comes back w/o the referer ending in /r, which is the random company name in this test).
Referer: http://chris.green2sustainable.com/r
Content-Type: text/html; charset=utf-8
Location: https://sdashchris.chargevault.com//update?key=710f9eb400&code=...
#5 Posted by Marc Guyer Support staff on 28 Nov, 2011 08:51 PM
Hi Chris -- I'm afraid I don't follow your question. Let me see if I can lay it out:
So, step (2) is not happening as you'd expect? The only way the hosted update page knows where to redirect to is from the HTTP referrer. CG does not alter the referrer URL in any way before redirecting.
#6 Posted by chaynes on 28 Nov, 2011 09:44 PM
Yes. (2) returns to http://chris.green2sustainable.com
not with the trailing /r in http://chris.green2sustainable.com/r as indicated by the Referer tag indicated above (which is taken directly from the about-to-be-sent CG request (which otherwise works). Do you look for Referrer instead of the misspelled Referer of the html standard?
#7 Posted by Marc Guyer Support staff on 30 Nov, 2011 04:00 PM
Hi Chris -- we can look in our logs for you to verify the referrer. Please replicate and send me:
Thanks!
#8 Posted by chaynes on 01 Dec, 2011 06:26 PM
1:25pm 12/1/11 the following was sent
Referer: http://chris.green2sustainable.com/b | profile = user.get_profile()
Content-Type: text/html; charset=utf-8 | profile.complete = True
Location: https://sdashchris.chargevault.com//update?key=d034a66610&code=502\| profile.save()
10ad11593428eaf8a4dde57f7ae0d
but redirection was to http://chris.green2sustainable.com/
#9 Posted by Marc Guyer Support staff on 01 Dec, 2011 10:50 PM
Thanks Chris -- The referer we're getting on that request is actually
http://chris.green2sustainable.com/sign-up. Here' the apache log entry:This looks like a client-side redirect since the user agent appears to be a standard mac/chrome agent. I suspect that you're trying to set the referer header on the server-side would would have no effect on a client side redirect.
My guess is that you're seeing
http://chris.green2sustainable.com/in your browser when redirected back from the hosted pages because your app is again redirecting from http://chris.green2sustainable.com/sign-up to that location.#10 Posted by chaynes on 01 Dec, 2011 11:51 PM
The ../sign-up URL is the real address of the referrer, but my understanding is that with Referer: http://chris.green2sustainable.com/b at the start of the CG message above, redirection should have been to that ../b address, unless the CG setup indicated another update redirect, which it doesn't in this case.
Our django system does some URL rewriting, but it doesn't rewrite /sign-up: that's the URL for our signup page, which I modifying to use your payment hosting after we collect contact info.
#11 Posted by Marc Guyer Support staff on 02 Dec, 2011 02:04 PM
Your browser is resetting the referer to the browser referer. This is unavoidable so setting the Referer header server-side has no effect.
It's not advisable to rely on the referer anyway since browsers are not required to set it. It's better to use the return locations. Set the return location to some location in your app which will understand where the customer should be directed.
#12 Posted by chaynes on 02 Dec, 2011 03:16 PM
But the return locations are fixed, so how is our server to know which client is involved? It is awkward if they have to login again after they provide payment information.
And it seems misleading to say in your return locations page that it overrides referrer if in fact the referrer does not effect the return location at all.
#13 Posted by Marc Guyer Support staff on 02 Dec, 2011 03:53 PM
Is the customer not already authenticated to your app?
The return location (if set) and the referer are mutually exclusive. This is why it says that a return location overrides the referer.
#14 Posted by chaynes on 08 Dec, 2011 03:23 PM
Yes they are authenticated. But when they return to our app after making a payment through your hosting, how does our server know how to continue their session, or at least know who they are so it can automatically log them in with a new session?
The return location is not set in the CG configuration (it is fixed, so can't include customer id) and in our CG update request the Referer is set to a URL of ours that includes company id (or could be login id to recover session). Here's a sample CG hosting request contents (sent about 10:10 this morning):
Referer: http://chris.green2sustainable.com/h
Content-Type: text/html; charset=utf-8
Location: https://sdashchris.chargevault.com//update?key=fb224a0701&code=...
The Referer above is ignored: when the user clicks the link to return to our site on your hosting transaction confirmation page, my server is addressed without the /h suffix, and there is no referrer tag in your return message either.
#15 Posted by Marc Guyer Support staff on 09 Dec, 2011 02:19 PM
If they are authenticated to your app with a session then upon returning to your app the session should still be active. If not, they would be required to log in again, correct?
Again, here's our access log entry for the request you referenced:
The referer is "http://chris.green2sustainable.com/sign-up". This is set by the browser and can't be overridden on the server side.
#16 Posted by chaynes on 12 Dec, 2011 03:22 PM
It's working now. Zon tried unsetting Configuration > Settings > Your website > Default UR. It was overriding the Hosted Pages return URL setting (referer when that not set). This needs to be documented.
#17 Posted by Marc Guyer Support staff on 13 Dec, 2011 02:04 PM
Hi Chris -- You're correct. It turns out that we're using referer as a "last resort" to try to get the customer back to the correct location.
Removing the Default URL (or Customer Account URL) will cause problems. This is used liberally within the email notification templates in particular. It seems that you have a requirement to use the referer header to specify where a customer should be returned. Is this still the case? If so, I have some concerns:
I'd like to understand your plans and requirements better so that I can help. As I've said before, this system was designed to provide the return locations as the best option to ensure that customers are returned to the proper place. I must confess that I am confused why this is not an option for you.
#18 Posted by chaynes on 13 Dec, 2011 02:54 PM
Our clients are logged in when they are directed to your site to update payment information. When they return from your site they should continue their session without having to log in again. With a fixed return location we do not know who they are, so cannot connect with their existing session. When the default URL is not set, they do (at least in one test using Chrome) return to their existing session.
If they click on an email link while logged in, ideally they would connect with their existing session, but the expectation for doing so is low in that circumstance so if they don't in that event, we're not concerned.
As noted earlier in this thread, we can (have) provided the referer programatically in our CG hosting call, so that should be independent of the browser.
#19 Posted by chaynes on 19 Dec, 2011 03:19 PM
We can directly code all the Default URL references in the email templates. Is there any other reason why we need this field, which gets in the way of your handling of redirection? If not, it seems we can consider this issue resolved (though in need of better documentation).
#20 Posted by chaynes on 16 Jan, 2012 03:12 PM
Please respond to the question in the previous post.
#21 Posted by Marc Guyer Support staff on 18 Jan, 2012 03:15 PM
The Default URL is a convenience so that you don't have to directly code it in the emails. I don't see any trouble with doing what you suggest.
chaynes closed this discussion on 18 Jan, 2012 03:34 PM.