The Foxy forums are on the move!

We're in the process of moving our forums over to a new system, and so these forums are now read-only.
If you have a question about your store in the meantime, please don't hesitate to reach out to us via email.

Understanding the subscription process with Foxycart's API

flinx777flinx777 Member
in Help edited November 2015
We are building a few features into a subscription based setup in our PHP CMS (MODX) and the client has requested that we setup the ability to allow customers to both be able to cancel directly in the login area we're building as well as being able to cancel through a link we email to them. So here's our question(s) for you as we're working through this.

In our setup we are storing customer transaction details on our system the first time they purchase a product or a product subscription. For subscriptions we are capturing the freq, endate, next_date, product etc. and storing it in our system (MODX).


* What will happen if the customer continues their monthly subscription and does not cancel: does foxycart re-run the data feed api at specific intervals?

* How are we going to test this if our current store is in test mode (do we have to go live to have Foxycart re-run the data feed API)?

* Does FC pull the customer txn_id for that specific subscription into the API feed and re-run the data feed so that we can do something on our part to update the transaction details that we originally stored? Like update the next_date that we will get from the data feed xml response if Foxycart re-runs the datafeed? Is it possible to run this scenario in test mode? I know I asked this above but double checking :)
  • fc_adamfc_adam FoxyCart Team

    Subscriptions are automatically re-run at their specified interval. Each time they are re-run, that triggers a brand new transaction, and that transaction will trigger an email receipt and the datafeed as any normal transaction would. You can then keep any details you have up to date on your side using that information.

    You could also use the API to fetch current and up to date information about the subscription as well - so you wouldn't need to store all of the information, just the sub_token to allow you to fetch that information with the API.

    Subscriptions and the datafeed work just fine in test mode. There isn't too much that doesn't work in test mode - the main things are being able to accept actual money and you're unable to select purchase orders as a payment method in test mode. Everything else should work as expected.
  • @fc_adam

    Thanks for your follow up...that helped a lot.

    Got a few more questions for you:

    * So if billing the customer for their subscription (i.e. every month) triggers a new transaction, what's happening to the original transaction details or transaction id? Like the end_date and next_date fields ... do they change as well dynamically or is that not being touched by FC? Is FC is just billing the customer based on the newest transaction details or id? Can you clarify that a little more please?

    * This is currently what we are going to do: we're going to disregard the old transaction details once we find a current transaction detail with the same sub_token. So I guess we are on the correct path (?), but we just wanted to know what's happening on the original transaction details so that we can also adjust the old details on our end.

  • fc_adamfc_adam FoxyCart Team

    The transaction ID attached to a subscription is related to the last transaction for the subscription - so it will change each renewal. The sub_token is the persistent identifier for a subscription. The actual make up of the product(s) in the subscription remain the same from renewal to renewal unless you change them. Does that answer your question?
  • flinx777flinx777 Member
    edited November 2015
    Is fc editing the old txn details out from the original txn_id? Because I know that fc is giving a new response on every txn run but I wonder if the old txn details are being changed.
  • fc_adamfc_adam FoxyCart Team

    I'm not sure I understand the question there, but as soon as a transaction is completed by either the customer or a subscription renewal - it's not altered.
  • @fc_adam you had said earlier:
    Subscriptions are automatically re-run at their specified interval. Each time they are re-run, that triggers a brand new transaction.
    What we want to know is whether you are altering the original transaction details like set the end_date or next_date after a renewal.

    We ask because we are capturing the xml in every transaction and we figured out that you are generating a new set of transaction details if the customer cancels the subscription. SO transaction ID 1 from the original txn has different txn details than the newly generated transaction (example txn_id 2) from the renewal/cancellation of txn_id 1.

    Question: on renewal, are you editing the end_date/next_date of txn_id 1 in case of renewal? Or is fc already disregarding that txn_id 1 and should we just now focus on txn_id 2 which is the newly txn generated from the renewal of txn_id 1?

    I hope that makes sense. Basically we just want to know if they are altering the previous transaction details.
  • fc_adamfc_adam FoxyCart Team

    Hmm - sorry - I think I still might be missing you here. Could you clarify exactly what you're meaning when you refer to "transaction details"?

    I'll try to clarify with what I think you might be referring to. When the customer purchases a subscription, that creates a subscription within your store. That subscription will include the broad settings for it - including start, next and end dates, past due amounts, frequency, last transaction ID and the transaction template - which is an XML representation of the contents of the subscription cart.

    When a subscription renews, it will create a new transaction using all of those details as required and the subscription object will be updated. The next date will be adjusted based on the frequency, the last transaction ID will be updated, or if the transaction fails the past due amount will be updated.

    The historical transactions that have been created aren't modified - it will list any subscription details embedded within it as it was at that point in time. So for example, if I purchase a subscription on the 1st of January with a 1 month frequency, the next date at that time will be the 1st of Feb. That's transaction 1. When the subscription renews, a new transaction is created for this renewal, transaction 2, and the sub will then have a next date of 1st of March.

    At this point, if I view transaction 1 using the API or the admin, the subscription product contained in that transactions cart will still list that the subscription had a next date of 1st of Feb. The transactions created from a subscription aren't modified at all - they're a historical representation of the transaction that occurred.

    The latest transaction that has occurred for a given subscription will always contain the most up to date representation of it - whether that be the contents of the cart, the customers address or payment details, or when the subscription will next occur or end. You can also always get the most current details for a subscription by looking directly at the customers subscription.

    Does that help? If not - if you could clarify further, that would be great.
Sign In or Register to comment.