Recent activity
Subscribe to this feed
A comment on the problem "Spreedly asks for credit card details even if the account has enough credit on file to pay for the next subscription" in Spreedly:
Fantastic feedback. The key is that we need to only collect credit card details if they're not already on file; I think you're correct that we should continue to collect even if the charge is $0 in the case of missing or invalid payment information. – Nathaniel Talbott, on December 24, 2009 14:53
Nathaniel Talbott replied on December 23, 2009 21:27 to the question "Moving current subscribers over to Spreedly" in Spreedly:
You'll have to talk to Authorize.Net, as we do not know of any way to extract card data out of their CIM for Spreedly to use. Unfortunately one of the downsides to the gateway-specific card storage solutions like the CIM is the high level of lock-in that they entail.
Assuming you could extract the card data out of the CIM, then you would be able to use the Spreedly Payments API to get it into Spreedly and simultaneously set up subscriptions for your existing subscribers.
Nathaniel Talbott replied on December 19, 2009 18:12 to the problem "Can't wipe a test site" in Spreedly:
Nathaniel Talbott replied on December 19, 2009 01:35 to the question "pay as you go" in Spreedly:
While it's looking like it won't be quite ready for your use by year's end, the first half (tracking fees) just got deployed for internal Spreedly use today. We hope to have the second half (charging for fees) deployed and in use internally by year's end, and then it's just a matter of polishing it up for your usage.
Getting close!
Nathaniel Talbott replied on December 18, 2009 23:20 to the idea "Request from a customer in Asia" in Spreedly:
Paydollar isn't an option as far as we can tell - neither of their integration processes allow a completely automated transaction, which we have to have to do auto-recurring subscriptions.
If you wanted to dig in further you could get in touch with them and ask if they support reference transactions. Reference transactions work by capturing a transaction reference during the initial, subscriber-driven payment process. Thereafter, we would use an API to re-charge the payment method using the original transaction reference. I didn't see such an API in their published docs, but it may be that they provide it to some accounts.
Sorry we don't have a better option for you at this point - we would certainly *love* to expand into Asia. If you find another option you think might work definitely let us know!
Nathaniel Talbott replied on December 18, 2009 23:11 to the question "Grace Period" in Spreedly:
Nathaniel Talbott replied on December 17, 2009 22:39 to the problem "Users can view other's plans, name and email through changing the user ID in the subscribe link." in Spreedly:
While there's currently no potential for payment data to be exposed, we recognize the privacy concerns and are going to start allowing/requiring the token soon. The plan is to do it in a backwards compatible manner, so that if the token isn't passed in we'll simply not pre-fill any of the sensitive data. Technically the current plan will still be exposed, but we see that as being acceptable.
We may also allow you to toggle a setting on your site that makes the token required, but we haven't got it spec'd to that level yet.
We'll update on the blog and Twitter when this goes live.
Nathaniel Talbott replied on December 16, 2009 15:22 to the problem "Can't wipe a test site" in Spreedly:
Definitely sounds like something that needs fixing - can you email support@spreedly.com with the short name of your test site so we can investigate?
Nathaniel Talbott replied on December 16, 2009 15:21 to the question "Auto Renewal Cancallation Notice" in Spreedly:
A comment on the question "how do you test listening for changes in a rails app?" in Spreedly:
Oops! You're right; just replace "MD5" with "SHA1" and it should all work great. – Nathaniel Talbott, on December 12, 2009 13:43
Nathaniel Talbott replied on December 11, 2009 20:15 to the question "how do you test listening for changes in a rails app?" in Spreedly:
A comment on the question "how do you test listening for changes in a rails app?" in Spreedly:
Wow, that was hard to find. Turns out there's a hard to see typo; check out the test file in my updated gist for details:
https://gist.github.com/7a480e39b1232...
I also moved your require and configure out of the class definition, but that's just a stylistic change - it would've worked either way. – Nathaniel Talbott, on December 10, 2009 23:49
Nathaniel Talbott replied on December 10, 2009 23:41 to the question "Multiple Purchases of same subscription product" in Spreedly:
No, if they purchase the same subscription twice, it will just stack up the time. We don't currently support the same customer having multiple subscriptions, though many Spreedly clients have emulated it by selling "bundles", i.e. having a "5 job posting plan", a "10 job posting" plan, etc.
Sorry we're not quite there for you yet.
A comment on the question "PayPal, Can’t do API certs and Sigs at the same time" in Spreedly:
Aaron, sorry you had to got to all that trouble - we haven't exposed it in the UI yet, but we already support 3rd-party API, which would've allowed you to continue using signatures. We're hoping to get the UI exposed for that within the next few weeks, but in the meantime if you or anyone else wants to use signatures just drop us a line at support@spreedly.com and we'll get you hooked up.
Sorry for all the extra hassle! – Nathaniel Talbott, on December 10, 2009 13:30
Nathaniel Talbott replied on December 09, 2009 16:49 to the problem "Getting an error message that says: Information received from an Invalid IP address." in Spreedly:
I believe you have to get Sage to allow connections from the Spreedly IP's. I'm not sure exactly where it's configured or if you have to actually talk to them about it. Would love to know how that process works if you want to fill me in afterwards :-)
The Spreedly IP's are 208.78.98.158 and 208.78.96.164, and we'll update you in plenty of time if they're going to change.
A comment on the question "Cancel account through API" in Spreedly:
You can't - Spreedly keeps a permanent history of your subscribers past and present. It's important to keep the details since you may need to substantiate financial transactions, etc. – Nathaniel Talbott, on December 09, 2009 16:30
A comment on the question "how do you test listening for changes in a rails app?" in Spreedly:
The errors you're getting indicate that the Spreedly gem code is not being required. Can you paste your full failing test case up on http://gist.github.com/ and I'll give it a look? I'm sure it's something simple but it's hard to debug without context. – Nathaniel Talbott, on December 09, 2009 15:30
A comment on the question "Cancel account through API" in Spreedly:
We'll notify you when their "active" flag flips - it's the canonical indication of whether a customer has an active subscription. Typically you'll cache the state of that flag locally, and you can just notice when it changes to "false" and do whatever processing you need to do on your end.
Will that work? – Nathaniel Talbott, on December 09, 2009 15:28
A comment on the idea "My wish list for Spreedly" in Spreedly:
It's never had that effect on me - I always just think "argh, there's a coupon out there and I don't have it!"
Of course, our designer may have other thoughts, but it's good to think about alternatives to the status quo. – Nathaniel Talbott, on December 08, 2009 14:14
Nathaniel Talbott replied on December 08, 2009 01:31 to the question "Cancel account through API" in Spreedly:
You can't cancel a user's already paid for time through the API, but you can stop their auto renew:
https://spreedly.com/manual/integrati...
What 99% of users mean when they want to cancel is "don't charge me any more money", which is exactly what stop auto renew does.
Is there something about your use case that stop auto renew doesn't cover?
| next » « previous |
Loading Profile...





