How do past due subscriptions work?

EpotratzEpotratz Member
in Help edited November 2016
Hey Guys,

We only ship product when we get a successful payment. If a recurring transaction fails, and the customer updates their card info, we want foxycart to immediately charge the card for the regular recurring amount (is this considered a "past due" amount?), and restart the frequency (e.g., 30d) from the day of a successful payment.

However, we DO NOT want Foxycart to keep increasing the amount due month after month. (Not sure if this is normal behavior in foxycart)

As far as I know, we are unable to test any of this functionality because there is no way "test" failed cards and/or past due amounts.

Based on what we are wanting, should we leave this option unchecked?

image
Comments
  • And how would this setting affect the ability for customers to cancel subscriptions if they have a balance "past due"? Will it still require past due amounts to be paid?
  • fc_adamfc_adam FoxyCart Team
    @Epotratz,

    Good questions.

    The checkbox you've highlighted there does prevent the past due amount from being charged on the normal subscription renewal. This means that even if the subscription failed previously and has a past due, if it renews successfully on it's next renewal date, it won't charge that past due. It will stay against their account though.

    If the customer has a past due amount and loads their subscription using the sub token link to either update their payment information or cancel the subscription - it will charge them the past due amount at that stage. The past due amount will also increase with each failure - so if the subscription is for $10, and it fails twice, the past due amount will be $20.

    Finally - if the customer pays that past due amount - the subscription isn't altered at all - it will be set to renew at the next normal renewal date. For example, let's say you have a 1 month $10 subscription that renews on the 5th of each month, and the November 5th renewal failed. If the customer used the sub token link today to login and update their payment information, they would pay that past due amount of $10 due for the failed transaction on the 5th of November. The subscription would have a next renewal date on the 5th of December.

    In order to make the past due amount not be accrued, and to alter the next date after successful payment of the past due, currently you would need to build out a little integration with our datafeed functionality and our API to edit the subscription and update the subscription details. We are also discussing improvements to our past due functionality right now along these same lines to support it natively too.
  • EpotratzEpotratz Member
    edited November 2016
    Hey @fc_adam,

    In an effort to give my developer some clear instructions, do you have any suggestion for stopping the accrual of past due amounts? Or "fixing" the past due amount to the first past due amount that posts?

    As far as resetting the scheduled, here's the logic I see:

    When customer pays a past_due_amount, the next_transaction_date is moved forward by the frequency date.

    Is that something that we would accomplish through the API once the customer checks out?

  • fc_adamfc_adam FoxyCart Team
    @Epotratz,

    Sure - so this would revolve primarily around the datafeed endpoint - which will receive both the transaction and subscription datafeed payloads. The former being triggered for any transactions, and the latter being triggered daily and including a summary of information about subscriptions that have a past due amount, will be ending soon or have ended today, and also customers with payment methods that are about to expire. This will also make use of the API.

    For the transaction datafeed - you would perform two checks:

    1) Loop through the products in the cart, and if there is one for "Past Due Amount", then the customer has paid a past due amount for their subscription. You would then use the API to update that subscriptions next date to be 1 frequency away from today. Worth noting here - the email receipt the customer would have received would show the normal next date - so they wouldn't actually have any record that the next date has changed.

    2) Also looping through the products, if this isn't a past due payment, grab any sub token URL's and perform an API request to update them to clear out the past due amount. This request is needed as because you've checked the box to not charge past due amounts on subscription renewals, a successful renewal payment won't clear those out.

    Then for the subscription datafeed, you'll loop through all of the subscriptions, looking for any that have a past due amount that is more than one single renewal charge for the subscription. For any that meet those criteria, perform an API request to update the past due amount to just be a single cost.
  • @fc_adam,

    Based on Bretts advice from this thread, we could update the next_transaction_date by doing something like this:

    1. In the customer dunning email, modify sub_token URLs, with &cart=checkout&h:date_change=true params added. (and a url param about updating next day with 1 frequency from today?)

    3. When the user lands on the checkout, the checkout template looks for the date_change param, and if present, updates the custom date picker field.

    4. When the checkout is submitted, the datepicker custom field gets sent in the webhook. We find that and update the subscription via the API.

    Would this allow the correct 'next date' to show on the customer receipt?
    Then for the subscription datafeed, you'll loop through all of the subscriptions, looking for any that have a past due amount that is more than one single renewal charge for the subscription. For any that meet those criteria, perform an API request to update the past due amount to just be a single cost.
    It sounds like this logic could get really complicated since we have multiple discount possibilities, autoship add-ons, etc. The "single cost" will not be consistent. Maybe it would be best to just set a cancellation schedule of 30 days after the first failed transaction? This is our shortest subscription interval and would ensure past due amounts never exceed a single autoship. Sounds good?
  • fc_adamfc_adam FoxyCart Team
    @Epotratz,
    Would this allow the correct 'next date' to show on the customer receipt?
    If you set a custom field with the date value - that could display on the receipt as a custom checkout value. If the next date isn't changed prior to the actual transaction taking place though, the next date shown under the subscription in the cart on the receipt will still be the original next date. You could potentially change it using twig for the receipt and email if that specific custom variable is present too.
    It sounds like this logic could get really complicated since we have multiple discount possibilities, autoship add-ons, etc. The "single cost" will not be consistent. Maybe it would be best to just set a cancellation schedule of 30 days after the first failed transaction? This is our shortest subscription interval and would ensure past due amounts never exceed a single autoship. Sounds good?
    You can compare the past due amount to the order_total node, also on each subscription, to compare how many times it's failed. For example, if the order total is $25 and the past due is $50, then you know that it must have failed twice and can update it accordingly.

    You could also set the subscription cancellation schedule to just before it would renew normally as you noted.
  • @fc_adam,

    To allow changes in the next ship date during checkout, and to make sure this date is the only date shown to customers, it sounds like we need to...

    Hide and replace cart_next_date with a custom 'masked' date field masked_cart_next_date across all cart, checkout, and receipt pages and have the masked_cart_next_date use the following logic for the date value, applied in this order:

    - If customer has selected date value from datepicker, apply value to masked_cart_next_date;

    - If past_due_amount is more than zero, apply 'Today + Frequency" value to masked_cart_next_date;

    - If neither of the above, then take apply native value from cart_next_date to masked_cart_next_date

    When the checkout is submitted, the masked_cart_next_date field gets sent in the webhook. We find that and update the subscription via the API.

    Would this work?


  • fc_adamfc_adam FoxyCart Team
    @Epotratz,

    That would be the best way to go about it right now - there are a few pieces to come together, but would get you the solution you're after.
  • Hey @fc_adam ,

    Is there some type of past_due_amount or first_failed_transaction_date on the cart and checkout pages?

    I'm not seeing anything in the documentation here: https://wiki.foxycart.com/v/2.0/templates/view_data

    Looking for something to build our logic around on the "next ship date" if the order is past due.

    Thanks.
  • EpotratzEpotratz Member
    edited November 2016
    @fc_adam,

    Also, I manually entered a past due amount for a customer, to try and see the behavior in the cart.

    I saw the customers cart appeared like the screenshot below. It seems confusing to split the past due amount, show an open quantity field, and a "remove" option. And the "sub id: 341594" is also confusing.

    If the customer generates a past due amount from a failed credit card, will their checkout also look like this?

    image

    image


  • fc_adamfc_adam FoxyCart Team
    @Epotratz,
    Is there some type of past_due_amount or first_failed_transaction_date on the cart and checkout pages?
    We don't currently expose any values related to what the past due amount is within the JSON, or how long since/when the subscription first failed on the checkout. You can pick up the past due amount from the cart though as you noted in your screenshot.

    As a note - you wouldn't have to technically set the next date via the checkout in that instance. You could actually set it from the datafeed directly - as you can check if the past due amount was included in the cart and tell from that that the subscription has been brought up to date with this transaction. Unless you're wanting to allow the customer to customise the date still even when paying a past due amount.
    If the customer generates a past due amount from a failed credit card, will their checkout also look like this?
    If a customer has a renewal fail and so had a past due amount - and then hit your checkout to update their payment details, they would see the checkout in much the same way - with a past due entry visible as a cart line item (one per sub).

    You're right that the open quantity input is strange for what the past due product represents. I'll open a ticket to discuss this with the team and look at updating it's display. We have a ticket active for some broader improvements to how we handle past due amounts, but we could look at some quicker visual improvements in the short term. In terms of the "sub_id" field - you can hide that for now using CSS: .fc-cart__item__option__sub_id { display:none; }. If you wanted to set the quantity input to be read-only, you could edit the cart include template to check if the current product in the items loop is for a past due amount, and set the quantity to read-only, or hide it, for that product.
  • EpotratzEpotratz Member
    edited November 2016
    @fc_adam
    If a customer has a renewal fail and so had a past due amount - and then hit your checkout to update their payment details, they would see the checkout in much the same way - with a past due entry visible as a cart line item (one per sub).
    Based on manually inputting of the "past due" amount in admin, it looks like the quantity and price_each is not being shown properly in the cart for the past due balance(s). This makes it impossible to apply any logical rules in OrderDesk to convert these 'Past Due" payments into actual shippable orders.

    Can you guys apply the correct quantity and price_each to the past due line item in the cart? Maybe as a fast track fix in the next few weeks?

    This little fix would alleviate this whole problem.



  • ^^ Unless this is just a problem with manually entering a past due amount in the admin? Does the quantity and price_each normally get applied properly on a failed card attempt for a subscription?
  • fc_adamfc_adam FoxyCart Team
    @Epotratz,

    We have a ticket active for updating how we handle past due amounts. Currently it's just a single figure that represents the total amount that wasn't charged successfully - a combination of item total, shipping, taxes, discounts etc. Our plan is to give a more true representation of what is past due, breaking it out into it's individual pieces so that you can see exactly what was past due.

    For now - your best bet would be to use the normal subscription representation to see what the past due amount is for.
  • Hey @fc_adam

    In OrderDesk, we see a automated_makeup_payment of TRUE for some of our "past due" orders. Does this mean that the retry attempt worked at charging the customer on a past due balance? Rather than the customer updating their payment info?

    I do notice that all these orders also have a fc_subscription_update: 1 property too.

    Thanks.
  • fc_adamfc_adam FoxyCart Team
    @Epotratz,

    The automated_makeup_payment attribute is added on our side if it's an automated attempt to charge a past due amount - so it's done via the retry schedule in the admin, or an integration has triggered the rety attempt too. Not by the customer hitting the subtoken URL though.

    The fc_subscription_update attribute I don't believe is coming from us... perhaps it's coming from OrderDesk?
  • Ok that confirms what i needed. The fc_subscription_update is coming from the foxycart transaction datafeed, but might be transformed by orderdesk.
  • @fc_adam

    Not sure if this is related, but I'm curious about these checkout fields:

    fcpm: plastic_new|checkout
    fcpm: plastic_saved|checkout

    They don't seem to be related to the customer updating their card as I would expect, because sometimes the card stays the same even if it shows "plastic_new". Any idea what these fields are for?
  • fc_adamfc_adam FoxyCart Team
    @Epotratz,

    Those session attributes are from the analytics integration - and is dependant on the option they select on the checkout. They may have selected a new card and simply entered the same number if you're not seeing any change there.
Sign In or Register to comment.