Credit Card Pre Auth Timing out

Hi guys,

My customer let me know today that they are running into issues where the credit card pre-auth is timing out quicker than they are able to fullfill orders, which of course is creating a problem. My customer sent me this link to see if it was something that could be initiated when an order is placed through foxycart?

https://developer.authorize.net/api/reference/features/customer_profiles.html

or if this would even help alleviate the issue? and/or do you have any suggestions about how to pre-auth the cc without it timing out so that the order can be fullfilled?

thanks so much!
Comments
  • fc_marijafc_marija FoxyCart Team
    Hi @freshjones -

    Do you mind whispering the domain of your client? I'd like to get a look at the exact error message that's occurring – that'll help us to better recommend a solution to the issue.
  • freshjonesfreshjones Member
    edited December 2017
    hi,

    There isnt an error message per se...

    What is happening is that a customer places an order, their credit card is pre-authorized for the funds, then my customer will prepare and fulfill the order at which point they log into their payment processor and capture the funds.

    The problem is arising because the payment processor (authorize.net) is expiring the pre-authorization faster than my customer can fulfill their customers order, at which point they can no longer capture the funds and are forced to contact the customer and ask them for their cc info over the phone.

    of course this is not ideal, so they are looking for possible suggestions of either a) how to increase the amount of time a payment processor will hold pre-auth funds (research indicates this varies by merchant classification code, or payment vendors im not sure which) or b) create customer profiles within the payment processors system (link provided) so that if a pre-auth timeout occured my customer could use the profile to re-submit the order request and get paid without having to contact the customer again. or c) any other ideas you might suggest?

    thanks!
  • fc_marijafc_marija FoxyCart Team
    edited January 2
    @freshjones,

    Thanks for the extra details.

    Card authorizations will be dependent on the cardholder's issuing bank, and can vary quite a bit (between banks, debit v. credit, etc.). The gateway (generally) has no control over it, and can't even check to see if the auth has expired or not.

    In terms of how to approach it so it's not a problem - we'd recommend using Unified Order Entry. You will need to require customers create an account when they place their order, and then if the merchant misses the capture, they can go in and place an order on the customer's behalf. Here's our article on how it works: https://wiki.foxycart.com/v/2.0/unified_order_entry

    In terms of the Authorize.Net customer profiles - our integration doesn't currently make profiles for the customer on that side. It's something we may support in the future - but our UOE feature will get you a similar kind of experience in terms of being able to charge an existing customer further in the future.
  • brettbrett FoxyCart Team
    @freshjones Quick note: I just edited @fc_marija's response to clarify a bit about authorizations and expirations.

    Another, more advanced, possibility (instead of UOE) would be to create transactions via the API, and push them through. You could have a template set that has the gateway set to auth-only, and that'd be what customers use. Then have another that's set to auth+capture, and you'd use that to push through API-generated transactions.

    This is quite a bit more complicated, but we do have a platform user who's done this.

    Also, we have some auth/capture/void/refund functionality in a private beta for a few gateways. That wouldn't help directly with expiring authorizations, but it would allow for capturing (and/or editing the order before capture). Drop us an email if you'd like to get that going for your client.
  • fc_marijafc_marija FoxyCart Team
    @freshjones I wanted to bring up one more option that was suggested by someone else here. If you don't really need to authorize initially, you can set up the product as a subscription with a future start date and an end date (so it won't run as a subscription) shortly after the start date. Then the "subscription" would start and run a transaction through on the start date specified. It will end before the next run date so it won't try to charge again.
  • Thanks for the help i really appreciate it!

    @brett can you explain a bit further about the set up you suggested? I'm not sure I quite followed how that would get set up.

    I just spoke to my client about the suggestions listed here, and they were very hesitant about the UOE primarily because of the PCI DSS warnings issued on that page of your website. PCI DSS compliance was one reason they switched to FC in the first place, so having to take back that responsibility is not something they are willing to do.

    plus even with UOE it seems like my client would need to "recreate" the same exact order their customer had placed if it expired which im not sure if there is a way to duplicate orders or resubmit orders but if they had to do it manually be adding to cart that would be hugely prone to human-error.

    i'm not sure about the subscription angle at all, because we sell many many products and it seems a bit hacky to set them all as subscriptions, id like to avoid that route.

    ideally they are looking for a way to maintain pci compliance as current, but be able to resubmit an order it it expired, the authorize.net customer profiles seems like it would do this, so very interested to see if @brett approach is able to get close to that.

    thanks


  • fc_adamfc_adam FoxyCart Team
    @freshjones,

    PCI compliance is certainly a good thing to be aware of, and be cautious on how it affects you. The warning on the UOE documentation page is more focused on if you're manually handling/entering a customers credit card details onto the checkout. For the usage we described above, that's not something you would be necessarily doing though. Instead, you would use UOE to authenticate with the customers saved account - so you wouldn't need to enter in any payment details at all.

    That said, you would need to recreate the cart when using UOE in order to complete the transaction as required.

    The approach @brett was describing is an advanced approach that would require some custom development with our API to achieve, as well as making use of our template set functionality. The approach itself would be similar to the UOE approach in that it would result in duplicate orders within the store, but you could automate the creation of the second transaction with the API, and filter the transactions by the specific template set to only see completed transactions.

    As an overview - the set up would be as follows:
    * Two template sets on the store, with two corresponding payment sets. One payment set would set the gateway settings to authorize only, the second payment set would authorize and capture.
    * All orders placed by customers through your store would go to the auth-only template set. You could still manually capture these if you wanted to - otherwise you could ignore the authorizations and just manually capture using the next step to be consistent.
    * For manually capturing an authorization with the store, this is where the main portion of the custom coding would be required. You would need to set up a custom integration using the Hypermedia API. As an example, it could take a transaction ID as a reference, and from that it could fetch the transaction information and recreate a new transaction using the saved information. When recreating the cart, it would use the auth+capture template set instead, ensuring that the customer will be charged when processing. The integration would exist outside of the FoxyCart administration where the merchant would interact with it as a custom interface.
    * You will also probably want to update the receipt and email templates, to alleviate any confusion for customers between the two transactions. For example, you could check what template set is being used, and include a note accordingly to let the customer know that the transaction is still pending, or that it's now complete, based on whether it's the auth-only or auth+capture template set.
Sign In or Register to comment.