A payment method is not available for your subscription ??

chaynes's Avatar

chaynes

16 Nov, 2011 04:28 PM

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. Support Staff 1 Posted by Marc Guyer on 18 Nov, 2011 10:03 PM

    Marc Guyer's Avatar

    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. 2 Posted by chaynes on 18 Nov, 2011 10:35 PM

    chaynes's Avatar

    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. Support Staff 3 Posted by Marc Guyer on 19 Nov, 2011 01:10 PM

    Marc Guyer's Avatar

    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:

    1. CG account has only one (non-free) pricing plan configured
    2. CG account allows signups on paid plans without payment method
    3. Customer is subscribed to plan via API (no payment info)
    4. Customer is directed to hosted pages update page to add payment method
    5. Can't add payment info!

    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. 4 Posted by chaynes on 28 Nov, 2011 06:29 PM

    chaynes's Avatar

    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. Support Staff 5 Posted by Marc Guyer on 28 Nov, 2011 08:51 PM

    Marc Guyer's Avatar

    Hi Chris -- I'm afraid I don't follow your question. Let me see if I can lay it out:

    1. Customer completes an update via https://sdashchris.chargevault.com//update?key=710f9eb400&code=...
    2. Customer is auto-redirected to the HTTP referrer which referred the customer to the update page.

    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. 6 Posted by chaynes on 28 Nov, 2011 09:44 PM

    chaynes's Avatar

    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. Support Staff 7 Posted by Marc Guyer on 30 Nov, 2011 04:00 PM

    Marc Guyer's Avatar

    Hi Chris -- we can look in our logs for you to verify the referrer. Please replicate and send me:

    1. timestamp
    2. update link (like in comment #6) used to replicate
    3. expected referrer

    Thanks!

  8. 8 Posted by chaynes on 01 Dec, 2011 06:26 PM

    chaynes's Avatar

    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. Support Staff 9 Posted by Marc Guyer on 01 Dec, 2011 10:50 PM

    Marc Guyer's Avatar

    Thanks Chris -- The referer we're getting on that request is actually http://chris.green2sustainable.com/sign-up. Here' the apache log entry:

    chargevault.com:443 108.71.214.204 - - [01/Dec/2011:18:23:41 +0000] "GET //update?key=d034a66610&code=50210ad11593428eaf8a4dde57f7ae0d HTTP/1.1" 200 13089 1461506 "http://chris.green2sustainable.com/sign-up" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.121 Safari/535.2"
    

    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. 10 Posted by chaynes on 01 Dec, 2011 11:51 PM

    chaynes's Avatar

    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. Support Staff 11 Posted by Marc Guyer on 02 Dec, 2011 02:04 PM

    Marc Guyer's Avatar

    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. 12 Posted by chaynes on 02 Dec, 2011 03:16 PM

    chaynes's Avatar

    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. Support Staff 13 Posted by Marc Guyer on 02 Dec, 2011 03:53 PM

    Marc Guyer's Avatar

    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.

    Is the customer not already authenticated to your app?

    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.

    The return location (if set) and the referer are mutually exclusive. This is why it says that a return location overrides the referer.

  14. 14 Posted by chaynes on 08 Dec, 2011 03:23 PM

    chaynes's Avatar

    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. Support Staff 15 Posted by Marc Guyer on 09 Dec, 2011 02:19 PM

    Marc Guyer's Avatar

    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?

    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:

    chargevault.com:443 108.71.214.204 - - [08/Dec/2011:15:12:40 +0000] "GET //update?key=fb224a0701&code=043b830160ad45edb75003b44ae3d4be HTTP/1.1" 200 12670 1388469 "http://chris.green2sustainable.com/sign-up" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.121 Safari/535.2"
    

    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. 16 Posted by chaynes on 12 Dec, 2011 03:22 PM

    chaynes's Avatar

    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. Support Staff 17 Posted by Marc Guyer on 13 Dec, 2011 02:04 PM

    Marc Guyer's Avatar

    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:

    1. There's no guarantee that all browsers will honor the referer header. This could result in stranded customers.
    2. Customers must always be redirected from your site so that you may set the referer with the redirect. This precludes you from using email notifications to guide customers to update their information when required. This could result in stranded customers.

    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. 18 Posted by chaynes on 13 Dec, 2011 02:54 PM

    chaynes's Avatar

    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. 19 Posted by chaynes on 19 Dec, 2011 03:19 PM

    chaynes's Avatar

    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. 20 Posted by chaynes on 16 Jan, 2012 03:12 PM

    chaynes's Avatar

    Please respond to the question in the previous post.

  21. Support Staff 21 Posted by Marc Guyer on 18 Jan, 2012 03:15 PM

    Marc Guyer's Avatar

    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.

  22. chaynes closed this discussion on 18 Jan, 2012 03:34 PM.

Discussions are closed to public comments.
If you need help with Cheddar please start a new discussion.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac

Recent Discussions

28 Mar, 2024 10:45 PM
24 Jan, 2024 08:33 AM
11 Jan, 2024 07:13 AM
30 Nov, 2023 02:07 AM
22 Nov, 2023 08:41 AM