Setup charge on changin plans

Nash Kabbara's Avatar

Nash Kabbara

06 Oct, 2009 03:42 AM

Is it possible to have the customer charged the setup fee after their current period ends instead of immediately?

Or maybe not charge customers the setup charge if they're already on a paid plan?

The way our billing works is a customer signs up for Plan A (50 setup + 50/month), then if they switch to Plan B (100 setup + 100/month) in 10 days, we'd want them to pay $100 at the end of the billing cycle and not a setup fee of 100 then again in 20 days another 100.

I guess the reason I'm describing that way is because your system charges at the end of the cycle and we want to charge at the beginning of it. But then we run into this problem when someone switches because of the setup charge effect.

Any solutions?

Thanks.

  1. 1 Posted by Nash Kabbara on 06 Oct, 2009 05:08 AM

    Nash Kabbara's Avatar

    Hi,

    Is it possible to change the text of the setup charge, "Subscription Setup", to something else?

    We advertise that we don't charge a setup fee, but we do charge upfront and we don't want our users to be confused.

    Also, as far as JSON responses (I'm using the ruby gem), when I get something like

    Precondition Failed: Array (

    [ccNumber] => Array
        (
            [ccnumChecksum] => '4111111111111110' is not a valid credit card number
        )
    

    )

    I should be able to parse it with JSON.parse, no? I keep getting a parse error.

    Thanks.

    Looking forward to using CG.

  2. Support Staff 2 Posted by Marc Guyer on 06 Oct, 2009 03:58 PM

    Marc Guyer's Avatar

    Is it possible to have the customer charged the setup fee after their current period ends instead of immediately? Or maybe not charge customers the setup charge if they're already on a paid plan?

    Yes. If the customer has already paid a setup fee and they change to a different plan with the same setup fee type (based on setup charge code), then they do not pay the setup fee again. See the Setup Charge KB article for more information.

    Is it possible to change the text of the setup charge, "Subscription Setup", to something else?

    Yes. You have full control over the content of emails sent by CG on your behalf. We're in the process of writing a KB article on the subject but in the meantime, checkout the 'Syntax Reference' link in the email template interface. Specifically check out the 'Payment Receipt' notification template. This includes a {$charges} array that you can loop through using Smarty syntax. The {$invoice.asciiLayout} variable is just a convenience so you don't have to create your own invoice template in the email. If you want to change the terminology generated by the {$invoice.asciiLayout}, you must make your own layout representation in the template. I'll try to remember to post here when the KB article on the subject is complete. In the meantime, please don't hesitate to ask questions about it.

    I should be able to parse it with JSON.parse, no? I keep getting a parse error.

    Yes, you should but there is a bug. The json encoded string is not getting through. The bug has been fixed but has not yet been released. It should be in the next couple of days.

  3. Marc Guyer closed this discussion on 06 Oct, 2009 03:58 PM.

  4. Nash Kabbara re-opened this discussion on 06 Oct, 2009 05:36 PM

  5. 3 Posted by Nash Kabbara on 06 Oct, 2009 05:36 PM

    Nash Kabbara's Avatar

    OK, I'll write a small script to test the setup charge logic, but regarding the JSON bug, how do your production clients parse errors currently?

    If we're unable to parse out the error response, how can we tell our users what to fix/change in order to try again?

    Thanks!

    -Nash

  6. Support Staff 4 Posted by Marc Guyer on 06 Oct, 2009 06:50 PM

    Marc Guyer's Avatar

    Current production clients don't depend on CG to validate their user input. Besides standard string length limitations, the only items that your users could enter and fail validation are email address, credit card number, credit card expiration date and zip code. These can all be effectively validated on your app's side and fit nicely into your current validation and error reporting scheme. If CG returns an error, this should be a fatal error in your application. The error message is for your benefit, not your customers.

    Email address can be validated in any number of ways. The CG validation first ensures that the email address is in a valid format. Then we check to make sure that the domain part is a valid hostname that accepts email (by ensuring that it has an MX DNS record).

    Credit Card numbers are validated on the standard credit card checksum algorithm (Luhn algorithm).

    Expiration Date is easy. Just make sure the date is in the future.

    Zip code, again, is easy. Just make sure it's 5 digits. It's not an integer. It can start with zeros.

    There are many open source systems that include validators for all this stuff. I'm sure there are some Ruby gems out there. Are you using Rails?

  7. Marc Guyer closed this discussion on 06 Oct, 2009 06:50 PM.

  8. Nash Kabbara re-opened this discussion on 06 Oct, 2009 07:52 PM

  9. 5 Posted by Nash Kabbara on 06 Oct, 2009 07:52 PM

    Nash Kabbara's Avatar

    Yup, I'm on Rails. Any ideas on what's good for the types of validations you
    mentioned?

    I'm sorry I didn't mean user input validation in my ticket, what I meant is
    auth failures due to AVS or bad expiration dates, etc... Isn't the response
    returned in JSON also in these instances? If so, we still need to tell the
    customer that they entered the wrong address or wrong expiration date and that
    they must rectify.

    Also in the instance of a timeout between you and Auth.net. We'd want them to
    try again.

    On another note, are you planning on integrating with other gateways in the
    future?

    Thanks.

    -Nash

  10. 6 Posted by Nash Kabbara on 06 Oct, 2009 09:54 PM

    Nash Kabbara's Avatar

    Marc,

      Do you guys have any fake CC data to simulate timeouts, and auth errors like
    insufficient funds or bad AVS, etc...

      Thanks.

    -Nash

  11. Support Staff 7 Posted by Marc Guyer on 06 Oct, 2009 10:11 PM

    Marc Guyer's Avatar

    I put out some feelers about your validation in Rails question. Here's one response from another CG user:

    For validation I use Rails built-ins, plus ActiveMerchant::Billing::CreditCard with require_verification_value set to false.

    We're currently returning gateway errors in their raw format. There are many types of errors some of which are a bit cryptic. We'll be making a large push to abstract those errors so that they can be more effectively handled on your side. We've already done the bulk of the work but have yet to begin hooking that into the error reporting in the API.

    It's interesting that you would ask about other gateways in the same post. Yes, we certainly intend to support more gateways. Abstraction of error codes and messages is an integral part of this effort. We want the same type of errors from different gateways to have the same top level error code so that you don't have to change your error handling if you change to a different gateway.

    Once this work is complete, we'll make some detailed error handling documentation available.

    Do you guys have any fake CC data to simulate timeouts, and auth errors like insufficient funds or bad AVS, etc...

    Authorize.Net does have such a credit card but it only works when using a specific type of integration. We're not using that type. I've already voiced my displeasure with Authorize.Net.

  12. Marc Guyer closed this discussion on 06 Oct, 2009 10:11 PM.

  13. Nash Kabbara re-opened this discussion on 06 Oct, 2009 10:23 PM

  14. 8 Posted by Nash Kabbara on 06 Oct, 2009 10:23 PM

    Nash Kabbara's Avatar

    Hmmm. So for right now, if all customer info passes our validation and your validation, but Auth.net returns a failure due to say, wrong AVS or bad exp date, how are we supposed to handle it?

    From what I'm understanding, we would simply tell the user the payment failed without any meaningful message so they may correct their error. Which might make the customer not sign up.

    Am I understanding this right?

  15. Support Staff 9 Posted by Marc Guyer on 08 Oct, 2009 01:21 PM

    Marc Guyer's Avatar

    Nash -- Here's a proposal for improved error handling. Let me know what you think of this technique. Once the plan is locked in and deployed, we'll put a nice doc together. It shouldn't be long. Maybe a week or two. This it top priority.

  16. Support Staff 10 Posted by Marc Guyer on 12 Oct, 2009 03:05 PM

    Marc Guyer's Avatar

    Nash -- There's been an update to the above referenced proposal. Please let us know if you have any questions.

  17. Support Staff 11 Posted by Marc Guyer on 22 Oct, 2009 06:23 PM

    Marc Guyer's Avatar

    Nash -- We went with something much more simple than the above mentioned proposal. It is actually what we had planned all along... It was just released this afternoon:

    Change Log

    Error Handling

    Error Simulation

  18. Marc Guyer closed this discussion on 22 Oct, 2009 06:23 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