Wp-calypso: Store Orders: Payment process for new orders

[ryelle]

Splitting this discussion out of #15679 and #20758 – When manually creating a new order for a customer, the customer needs to pay for the order somehow. Scenarios:

• An order is placed in person/by phone, and payment is taken directly from the customer, the order can be marked as paid when created.
• An order is placed but payment is not taken immediately, and the store owner needs to send an invoice to the customer either via email or manually sending a link to the payment page.

---

We need to set a default payment method, so that "Pay $20.00 via [method]" displays correctly (see incorrect below). We might be able to set it to "Manual Payment" or something like that, rather than picking specifically check/stripe/paypal etc. The customer can pick the real payment method on the payment page.

We started talking about adding the direct link to the payment page in the success notice, but maybe we can use the payment card on the just-created order? We could also/instead add a button to trigger the invoice email. That's this section:

cc @jameskoster @kellychoffman

[jameskoster]

Hmm, couldn't we take the payment method selection when the order is originally created? Then this section will change to match whatever was specified there.

IE if it's an offline method;

Awaiting payment of x via check [Mark as Paid]

If it's an online method;

Awaiting payment of x via Stripe [Send invoice] [Copy link to payment page]

We _could_ include a way to process online payments by the customer supplying their card details _during the order creation process_, but should we encourage that? Aren't there PCI issues?

We should probably revisit the designs for this specific interaction.

[jameskoster]

Just spoke with @kellychoffman about this. We flip-flopped a bit on whether we could take payment during the order creation process and figured that if we can save the order as a draft when the store owner clicks the "process payment" (or whatever) button it would hopefully be possible?

Either way, we need an answer on the PCI detail. I'm gonna post about that now.

When we have all the infos we'll rustle up a design.

[ryelle]

couldn't we take the payment method selection when the order is originally created

Sure, but the user can change which method if multiple are offered on the site when they go to pay. Maybe that's not a problem.

We could include a way to process online payments by the customer supplying their card details during the order creation process

What if the store owner uses the customer payment page to enter their card details via Stripe? Then we're not handling CC data, and we don't have to process 3rd party transactions (like, how does the store owner get their money from us?) – do you think that would work as a flow? In that case, for pending-payment orders, we could redirect the page to the payment page after a successful order creation.

[jameskoster]

Sure, but the user can change which method if multiple are offered on the site when they go to pay. Maybe that's not a problem.

Yeah I think that's unlikely.

What if the store owner uses the customer payment page to enter their card details via Stripe?

Using our payment form to process the payment makes perfect sense. I'm just not sure about the security implications of taking credit card details over the phone. I'd like us to button that up before deciding how to process. See p2y3YZ-3fN-p2.

[timmyc]

To get some context on this, I created an order using wp-admin to see how things flow there wrt payments. From that experience, and chatting with @ryelle about some different approaches, it seems to me we should probably work with the existing options that are provided from Woo core for this first iteration.

So after creating an order, where an online payment method is desired there could be a couple of options:

• Order is created, and shop owner is redirected ( or new window is opened ) to the order payment page of the site, i.e. checkout/order-pay/ID/?pay_for_order=true&key=wc_order_11111secret. Benefits here being, the shop owner could then fill out payment information for any payment gateway wether it be over the phone or a walk-in customer to a shop. The key needed for the URL is already included in the response of the /wc/v3/orders/ID response, so building the URL to the payment page should be a quick task.
• The option to email the invoice to the customer is presented - much like the action menu in wp-admin. The order invoice includes the link to the same payment page, and allows the customer to input their payment data, and also verify the order is correct prior to the purchase. I don't believe there is currently a way to trigger this email via the API ( /cc @justinshreve just in case because my recent API track record is spotty 😄 ) - so we would need to create an endpoint in wc-calypso-bridge to fire off the email sending logic like what is currently in core #

Perhaps it would make sense to show to action buttons that do the above options too after an order is created that needs payment. Maybe the Send Invoice button would open a dialog for a the recipient email address - which could default to the email on the order, but would allow for changing the recipient.

The beauty of the invoice/payment page route, is it entirely takes any concern of PCI compliance off the table, as the customer is entering in their own payment data. On the topic of PCI compliance though, even if we prevented entry of customer payment data in Calypso, shop owners could still take cc#s over the phone ( or via email - I've seen it many times ) and we can't really control that via code... so not sure if we should be too concerned about compliance in this scenario.

[justinshreve]

I don't believe there is currently a way to trigger this email via the API ( /cc @justinshreve just in case because my recent API track record is spotty 😄 )

😆. I don't know of anything either so I think we'll indeed need something in wc-calypso-bridge.

[timmyc]

thanks for the sanity check @justinshreve - i'm all about creating redundant endpoints, but only like to do so once per month 🕺

[jameskoster]

Chatted through this on Slack with @timmyc. To clarify; the PCI concerns were around enabling Store Owners to submit a payment form on the order page so they could effectively take orders over the phone in a single flow.

We decided to leave that for later. For now, the store owner will just be able to send the customer an invoice (with a payment link) rather than actually taking payment over the phone.

[timmyc]

Thanks for closing the loop here @jameskoster - you mentioned in our slack chat that there was an original design/concept for having the "Customer Payment Page" link in the activity log - is that how we should move forward here, or should we have another more prominent link shown elsewhere to the page?

Also should we pursue the "email invoice" option now too, or let that wait for another iteration? That feature would likely require some custom API work in wc-calypso-bridge

[jameskoster]

you mentioned in our slack chat that there was an original design/concept for having the "Customer Payment Page" link in the activity log - is that how we should move forward here

That was when we thought we'd be taking payment on the order screen.

Seeing as we aren't going to be doing that (for now at least) the email/invoice will need to be sent regardless. Then it's a question of what's most useful to a Store owner in the event of a customer losing their invoice email. Is it "Resend invoice" or "Copy payment link". Or is it both? Resending the invoice probably makes most sense and should be easiest seeing as the functionality already exists in core.

I think adding a "Resend invoice" button the the header bar for orders pending payment is the quickest and cleanest solution for now.

[ryelle]

Is it "Resend invoice" or "Copy payment link". Or is it both?

Both - we want to be able to reset the invoice in general (like you mentioned, a customer could loose it), _and_ we want the store owner to be able to get to the customer payment page so that they can take payments through that page (so it's probably not a button to copy a link, but a direct link).

[jameskoster]

I'm just not sure we need the copy/direct link feature. Reasons;

• The invoice email _contains_ the link already.
• A direct link as you suggest won't actually work for the Store Owner (you need to be logged in as the customer to access the payment page). So when they click it they'd tumble into a weird experience.
• How does the Store Owner communicate the link to the customer? Text or IM make sense if they have the facility - but at that point you might as well just resend the email?

The potential for confusion doesn't seem worth it to me. Resending the invoice should resolve the vast majority of cases.

[kellychoffman]

Okay, sounds like the conclusion is:

New order

When creating a new order and the customer has not paid, the success message on 'Save order' should read:

Order successfully created. An invoice has been sent to the customer.

'Resend invoice' button appears in header.

Editing an order

When editing an existing order, the success message on 'Update order' should read:

Order successfully updated. Send new invoice to customer

'Resend invoice' button appears in header.

Does that sound right @ryelle @jameskoster?

[timmyc]

Seems reasonable to me. With the links to re/send invoices to the customer we will need to tackle triggering emails via the API:

https://github.com/woocommerce/wc-api-dev/issues/10

Or alternatively, for time-sake, we can create a quick one-off solution in wc-calypso-bridge just for sending the order invoices.