Bruce,
I'd like to take a stab at adding ARB cancel/modify. Do you see any
issues with the following logic?
Add processor.cancel() and processor.modify_recurring_charge_amount()
methods to payment/modules/authorizenet/processor.py , which will
access the Authorize API the same fashion as the existing
process_recurring_subscription().
The only unique information needed to send these requests is the
orginal Order's Authorize.net ARB subscription_id stored in:
OrderPayment.transaction_id
for cancel():
checkout/authorizenet/arb_cancel_subscription.xml
<?xml version="1.0" encoding="utf-8"?>
<ARBCancelSubscriptionRequest
xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
<merchantAuthentication>
<name>mytestacct</name>
<transactionKey>112223344</transactionKey>
</merchantAuthentication>
<refId>Sample</refId>
<subscriptionId>100748</subscriptionId>
</ARBCancelSubscriptionRequest>
Similarly, for modify_recurring_charge_amount()
checkout/authorizenet/arb_modify_recurring_charge_amount.xml
<?xml version="1.0" encoding="utf-8"?>
<ARBUpdateSubscriptionRequest
xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
<merchantAuthentication>
<name>mytestacct</name>
<transactionKey>112223344</transactionKey>
</merchantAuthentication>
<refId>Sample</refId>
<subscriptionId>100748</subscriptionId>
<subscription>
<amount>10.29</amount>
</subscription>
</ARBUpdateSubscriptionRequest>
On the Satchmo side, we would modify the existing subscription
creation method to set the OrderItem.expire_date to NULL initially.
Case 1: Subscription Order Cancel
If a user cancels a subscription, call processor.cancel(), which
performs the following:
1. look up the corresponding subscription_id
2. send a cancel message to the Authorize API
3. set the expire_date for the corresponding entry in the Order table.
Case 2: Basic Subscription Order Upgrade/Downgrade (using credit card
info on file at Authorize):
If an existing subscriber upgrades or downgrades to a plan with a
different price, call processor.modify_recurring_charge_amount(),
which does the following:
1. look up the corresponding subscription_id
2. send a modify message to the Authorize API, changing the price to
reflect the new subscription plan price
3. set the expire_date for the original subscription plan entry in the
Order table to the current date.
4. Create the new order: insert new rows in the various shop_order
tables for the new subscription plan order, using the same billing
information as the original plan
On Nov 17, 2:13 pm, "Bruce Kroeze" <[email protected]> wrote:
> Over the last few days, I've been working hard to improve our recurring
> billing support in Satchmo. I've just committed the result of that work to
> the trunk.
> It is all good news. No backward-incompatible changes other than the minor
> ones I introduced last week.
>
> The best news is that we now have two payment processors which understand
> "native" recurring billing. That means if your customer pays for a
> subscription product with Paypal or (new) Authorize.net, they will get
> automatically billed on the basis you set up.
>
> This is pretty huge, I think. I'd love to get feedback from people using
> the system, so that I can extend it even more. For now, the areas which
> need improvement are:
>
> - Cancel subscriptions from Satchmo. Preferably both via Admin and Customer
> interfaces. This is easy to do in Authorize.net, I just haven't done it
> yet.
> - See status of subscriptions - for the user.
> - Update subscription status queries - could be automated for both
> processors, I believe.
> - Some interface in Admin to show subscriptions in a report. Of course, we
> need more reporting in general.
>
> I'd also like to figure out a way to make split payments easier to do for
> product variations. That way you could charge 50% now, and 50% in thirty
> days for entire product/product-variation sets. You know, the way they do
> it on TV ads. It would be a slick addition to Satchmo.
>
> These changes were sponsored by Juice Analytics (http://juiceanalytics.com).
> Thank you, Juice.
>
> --
> Bruce Kroezehttp://gosatchmo.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Satchmo users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/satchmo-users?hl=en
-~----------~----~----~----~------~----~------~--~---
