Not Voiding Prior Affirm Authorizations

[seandawes]

Steps to recreate:

• Customer adds item(s) to cart and selects affirm in checkout

• Customer gets approved but exits the site before completing an order or exits checkout

• Customer comes back to checkout and must get preapproved again even if cart total or items did not change

Issue:

• Multiple authorizations will exists on customers affirm account as well as under payment history of the Order ID which can be captured/voided. When processing the order you must manually void all prior authorizations and capture the affirm authorization that is the most recent. For customers who actually did purchase this leads to confusion that they have either multiple orders for the same item or multiple loans for the same order since their personal affirm will show all loans/preapprovals until the retailer captures/voids. See below example
  

• This also makes other customers who abandon before clicking to submit order be confused as they think they did order since their affirm account shows outstanding loan but they have no records of solidus store order (transactional email etc) since as far as Solidus goes they never completed the order. Example below of order/payment state in this scenario
  

Proposed Solution

• When an order is being processed any other payment method that has an open authorization should be voided when a new payment method is applied and able to be captured

• Potentially void authorizations of affirm orders after a certain time period to handle customers just verifying if they can get approved? Currently we do it after a number of days have passed. We manually go into our affirm merchant dashboard to find these authorizations that are tied to abandoned orders

[peterberkenbosch]

Part of the solution here will be to have the payment "captured" only as a part of the completion of the order and not on the payment step before the order has been completed.

est: 1d

[AlistairNorman]

Hi, I'm migrating a solidus project I work on with Super Good from a hacked version of spree_affirm to this gem and I ran into an issue that I think is basically what is being described here. I found that authorization happens in the AffirmController confirm action which is before the order is actually complete. Also autocapturing is set to false so it would not capture when the order was completed.

I ended up overriding a few things in the client's project. The affirm controller would just move the order to the next state. I essentially removed the override of autocapture to false, giving that method back its default behaviour. I also added a purchase method to affirm_client.rb which authorizes and then captures the payment so that those things can happen when the order is completed.

I'd be happy to contribute. I'll open a pull request next week if these changes seem reasonable to you. Thanks!

[seandawes]

@AlistairNorman There are numerous revisions to the affirm extension which are in testing on our servers now. You may want to wait to see the status which comes out via a blog post by @peterberkenbosch who did the work on improving Solidus - Affirm

[AlistairNorman]

Sounds good. I figured it would be best to get my pull request up while @peterberkenbosch was working on it so that we could get all the changes through at once. I'll definitely hold off if the issues around how authorization/capturing happens are being worked on by others. Thanks!

[peterberkenbosch]

Thanks @AlistairNorman! More then happy to see a PR for sure! here and/or at https://github.com/solidusio-contrib/solidus_affirm_v2.

I know there was a reason why we did not implemented the purchase method, but reading your explanation it makes sense to have that so we can follow the Solidus idioms around payment processing better.

[kennyadsl]

I think we can close this one now, thanks @AlistairNorman!

[peterberkenbosch]

Agreed! Closing this