Matt's dashboard

Matt shared an idea in Spreedly on November 13, 2009 19:39:

auto-detect credit card type

I've had a few of our own customers suggest this: detect credit card type based on the number, and pre-fill the dropdown with that.

http://en.wikipedia.org/wiki/Credit_c...

Matt replied on August 03, 2009 19:02 to the idea "Cool extra features?" in Spreedly:

Ditto: this is definitely something we need.

Matt replied on August 03, 2009 18:59 to the idea "a la carte add-ons" in Spreedly:

Jim: in the interim, we're accomplishing this by having users submit multiple payments. We give multiple subscriber_ids to a user in our system, and Spreedly charges them separately. It's definitely not ideal, but it works when you only have one or two add-ons.

Less-hackish direct support in Spreedly would be ideal.

Matt started following the idea "a la carte add-ons" in Spreedly.

Matt started following the idea "Implement discount vouchers" in Spreedly.

Matt replied on August 03, 2009 18:53 to the question "Can an admin change subscription plans for a subscriber?" in Spreedly:

Is there a way to do this such that the subscriber continues to renew?

Matt started following the question "Can an admin change subscription plans for a subscriber?" in Spreedly.

Matt started following the question "Letting Paypal users subscribe through Spreedly?" in Spreedly.

Matt replied on July 23, 2009 22:06 to the idea "Programmatic subscriber deletion, for production sites" in Spreedly:

Good to go.

One more piece of feedback on the new_subscriber_id. I agree, it definitely makes sense to make destructive operations more difficult. In that case though, an ActiveResource custom method would probably be easier to use, while still being obvious that you're being destructive:

"/api/v4/meresheep/subscribers/44/change_customer_id.xml"

...this way, in ActiveResource, you can do...

sub = Subscriber.find("44")
sub.put("change_customer_id", new_customer_id="55")

...instead of with the current API...

sitename = config["sitename"]
headers = {"Content-Type": "application/xml"}
data = "<subscriber><new_customer_id>55</new_customer_id></subscriber>"
Subscriber.connection.put("/api/v4/" + sitename + "/subscribers/44.xml", headers, data)

Thanks again...you guys are quick :)

Matt replied on July 23, 2009 20:32 to the idea "Programmatic subscriber deletion, for production sites" in Spreedly:

Great, thanks Nathaniel. A couple notes though:

1. After some fumbling, it looks like the "new_customer_id" API requires "email" as well. Why are both fields required for an update?

2. Why "new_customer_id" instead of just letting us set "customer_id" on the Subscriber, and save() the ActiveResource object? It dilutes the usefulness of ActiveResource a bit if I have to make custom REST calls for certain operations (like this).

Thanks again for the quick response on this, it was really helpful to us!

Matt replied on July 23, 2009 08:44 to the idea "Programmatic subscriber deletion, for production sites" in Spreedly:

Definitely a fair summary :)

I agree, we don't need to delete so much as be able to disable subscribers. Does Spreedly have it own "internal" ID for uniquely identifying customers? That would make things much simpler for dealing with these cases, since any changes we make to active/inactive, or even the customer_id, would not affect your ability to deal with the actual Subscriber object.

We actually ran into a related issue tonight: we accidentally typo'd a customer_id in the URL, and now there is no way to manually "fix" that Subscriber (POSTing to the subscriber with the corrected customer_id results in a 500 error).

Matt shared an idea in Spreedly on July 21, 2009 02:44:

Programmatic subscriber deletion, for production sites

There are cases where we may accidentally create a Subscriber against the production site (e.g. a bad payment URL with a bogus customer_id). We may also remove or disable accounts within our own system.

Currently, there does not appear to be any way to delete a subscriber in Spreedly if something changes in our own data model, and we want to clean out that particular subscriber. Basically, it would be awesome if the delete API that works on test sites would also work on a production site.

This would also avoid the need for us to special-case customer_id handling on the callback URL, for accounts that we have removed or disabled within our own data model.