Bug in CheddarGetter_Client::editSubscription()
The CheddarGetter_Client::editSubscription() method returns its results as a CheddarGetter_Response object, however the return value from request() is an empty string. This causes CheddarGetter_Response to spit out an error...
Warning: DOMDocument::loadXML() [domdocument.loadxml]: Empty string supplied as input in /home/fwdvault/frontend/includes/classes/CheddarGetter/Response.php on line 29
Fatal error: Uncaught exception 'CheddarGetter_Response_Exception' with message 'Response failed to load into the DOM. ' in /home/fwdvault/frontend/includes/classes/CheddarGetter/Response.php:30 Stack trace: #0 /home/fwdvault/frontend/includes/classes/CheddarGetter/Client.php(358): CheddarGetter_Response->__construct('') #1 /home/fwdvault/frontend/test.php(24): CheddarGetter_Client->editSubscription('2', NULL, Array) #2 {main} thrown in /home/fwdvault/frontend/includes/classes/CheddarGetter/Response.php on line 30
Per usual debugging, here's the input to request()...
https://cheddargetter.com/xml/customers/edit-subscription/code/2/pr...
Array ( [ccFirstName] => Joe [ccLastName] => Blower
[ccNumber] => VALID_CC_NUMBER_USED [ccExpiration] => 06/2011
[ccZip] => 90210 )
Also as an aside, the admin does not display the full billing info -- name, zip code, and 4 digits -- anywhere. I understand not showing the number, but having access to the info is helpful when charging issues arise.
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
Support Staff 1 Posted by Marc Guyer on 16 Sep, 2009 06:39 PM
edit-subscription was requiring a planId/Code in error. I'm surprised that scenario hadn't been tested before. I've added it to our unit tests and deployed a fix.
The last four digits and the expiration date are shown on the customer detail page. We're not currently storing any additional information but I can see how that could be valuable. I've added an item on our feature requests list to query the gateway for the billing information for display on-demand.
Marc Guyer closed this discussion on 16 Sep, 2009 06:39 PM.
Frank Koehl re-opened this discussion on 16 Sep, 2009 07:46 PM
2 Posted by Frank Koehl on 16 Sep, 2009 07:46 PM
That seems to have fixed the problem, however a call to edit subscription is making a call to Auth.net. I ran a single test to confirm your fix, and Auth.net again sent me a transaction receipt.
Since the subscription was merely changing the billable CC, should that have happened?
Combined with the account activity I described in my earlier bug thread, I feel like either something isn't right still, or I am misusing the API calls. Do you have any details that cover exactly when and how a charge occurs? Can you look into the activity I've triggered and see if anything's amiss?
Support Staff 3 Posted by Marc Guyer on 16 Sep, 2009 10:18 PM
If your API call changes the credit card (we check based on last four digits), then we inform the authnet CIM that the credit card has changed at which point authnet issues an auth-only transaction for $0.01 ($1 in testing). The auth-only transaction is used to ensure that the credit card is real and at least has a positive balance. It will not settle. This is a function of authnet.
This is the same process that takes place when a new customer is created with credit card information.
Marc Guyer closed this discussion on 16 Sep, 2009 10:18 PM.
Frank Koehl re-opened this discussion on 18 Sep, 2009 03:56 PM
4 Posted by Frank Koehl on 18 Sep, 2009 03:56 PM
Okay, some of the fog is clearing. So what do I have to do to actually see an actual monthly charge occur? Can I even do that with Auth.net in test mode?
Support Staff 5 Posted by Marc Guyer on 18 Sep, 2009 09:23 PM
Unfortunately, you have to wait a month. In test mode, if I recall,
authnet with decline the transaction with a test mode error.
While in dev mode (or without a gateway altogether), you could set
your plans to bill weekly if you want to see the invoice really
transacted and then you'd only have to wait a week.
You could configure a plan with a non-zero setup charge (again dev
mode or without a gateway). New subscriptions to the plan will
transact immediately.
Are you looking to test something specific?
6 Posted by Frank Koehl on 18 Sep, 2009 10:07 PM
Whoa hold up a second, are you saying that CG bills retroactively, instead of at the time of account creation? So if I set my billing up on a monthly basis, the user uses the service for a month before being billed for time used?
In that case, I need to do the exact opposite. What's the best way to make CG charge in advance for a billing period. I don't have a setup fee associated with the plan, rather the first month of service is simply due at the time of signup.
Yes, "specific" in the sense that I want to see the entire process play through. I'm not comfortable delivering something blind to my users. Of course I was working form the perspective of proactive billing, so if I can do that then this problem solves itself.
Support Staff 7 Posted by Marc Guyer on 21 Sep, 2009 04:24 PM
Yes, since CG is a subscription system with micro-billing or usage tracking features, the billing style is technically "in arrears". How could CG bill for some feature usage or overage if it hadn't occurred yet?
That said, we do have a solution for your intended billing behavior. The setup charge is the method for beginning a subscription for some initial cost as explained here. You might like to think of the setup charge as having some other name. It doesn't really matter what it's called -- it's just the amount that is billed immediately upon signup for the plan.
I can manually change some dates for you if you'd like CG to think that a customer or two signed up almost a month ago. This way, you would just wait a day or two before the next invoice becomes due.
Support Staff 8 Posted by Marc Guyer on 21 Sep, 2009 04:29 PM
One thing you might like to change if you don't like the word 'Setup' is the 'Payment Receipt' email notification template. Assuming, of course, that you use this notification feature.
This template, by default, includes the convenience of a pre-built ascii or html invoice layout which includes the word 'setup'. You may choose to build your own invoice layout with a different label for the setup charge.
I plan to write a KB article on the subject. If you'd like to build your own layout, I'd be happy to move that article up on my todo list.
9 Posted by Frank Koehl on 21 Sep, 2009 08:35 PM
Dunno why my searches didn't turn up that KB article, but thanks, Marc.
I may take you up on that invoice layout, but first I want to see the all the actual billing go through properly. At least as far as I can get it in test mode, anyway. I'm getting there.
10 Posted by Frank Koehl on 25 Sep, 2009 03:41 PM
Quick update: definitely going to use the CG Email Notification templates. That KB article on editing the invoice layout would be great.
Support Staff 11 Posted by Marc Guyer on 27 Sep, 2009 10:18 PM
Ok -- I'll start working on that. In the meantime, you can take a look at the Smarty documentation.
CheddarGetter's 'Payment Receipt' and 'Payment Declined' email templates have a {$charges} array available. You can loop through the {$charges} and list them any way you'd like.
Marc Guyer closed this discussion on 05 Apr, 2010 03:05 PM.