sjhudson

Our specific workflow is a bit unique, but the same issue would apply to any business in which the in-person contact is at the beginning of the production process and the customer is expected to pay before work starts (e.g., sign shops, or any other sort of custom manufacturing).

In our case, the customer is present to select a product, which we will then ship to them later. If the customer is unwilling/unable to check out online themselves (they can scan a QR code on their chosen product), a staff member creates the order for them using shop-as-client functionality on our site’s front end, which has logic to fill in specific order details in a structured form. The staff member selects a “check” payment type, which leaves the order in a “pending payment” state after creating the order (‘cod’ works also, but leaves it ‘processing’, creating the issue described in this ticket).

Currently, staff now needs to go into the admin console and change the payment type to “N/A” so the app will allow card payment (this is what I would like to avoid). They then load the order in the app, and process the in-person card transaction.

Although this issue occurs before the card is processed and therefore can’t be affected by the reader, we are using a Stripe BBPOS Chipper, which works flawlessly with your app. It seems to be a functionally equivalent device to to the M2.

The TFSW plugin is currently inactive, as noted in the SSR; we have used it in the past with the same workflow and their third-party app (which does support the ‘check’ payment method). Your app is otherwise more flexible for managing orders and incurs lower fees, so we would prefer to use it.

No, it is not a duplicate thread. They were split deliberately. This is an entirely different issue, relating to disallowed payment methods. The other one relates to order status after payment, as you correctly summarized. Please mark this issue open.