Posting a payment in swell without charging the payment method

[vettloffah]

I'm building a custom checkout that requires we use the Stripe "payment element" with the payment intents API to charge the customer directly.

Since the charge is done directly with stripe, I want to POST a payment to swell, to show that the order has been paid. But the problem is that when I post the payment to swell, swell creates a new charge, so the customer is being charged twice. Once using the stripe paymentIntents API directly, then again what creating the payment using swell.post('/payments').

So is there a way to post payment for record keeping, without actually creating a charge?

[ericingram]

There's 2 ways to work with payments currently:

1. Use an existing integration i.e. Stripe, and have it take your pi_ token to perform the charge for you. We also support other kinds of tokens for example.
2. Create a "Manual payment method" and perform the charge independently, but then refunds can't be automated through the dashboard. (We're going to introduce a new real-time webhook that would fix the issue with refunds from the dashboard eventually.)

Is there a reason you need to charge the customer outside of Swell instead of using the integration?

[vettloffah]

We need to accept ACH payments, and the easiest way to do this is using the new-ish stripe "payment element" instead of a "card" element, since then ACH and cards can be accepted in the same element (along with all of the other payment methods).

The problem is that using the payment element, you can no longer create a payment method separately from creating a charge - basically when you call stripe.confirmPayment, that is when the payment method and charge are created and you can't separate it.

So, then when the order is submitted and post the payment to swell, that is actually the 2nd time the payment has been charged.

Here's an example in stripe:

So, the manual payment method seems like a decent work around.

I was also thinking for another solution, we could use a "setupIntent" instead of a "paymentIntent" in the checkout flow, then when swell creates the charge it's the first charge. But, that might pose other issues with the swell integration that I'm unaware of.

[ericingram]

It seems like we should be able to avoid the 2nd charge by checking payment status first. What kind of token is being created in that case?

@vstudenichnik-insoft can you check on this?

[vettloffah]

I had a call with one of your engineers, and we were able to resolve this by passing the capture: false flag in the payment data:

const payment = await swell.post('/payments', {
			order_id: order.id,
			method: paymentType,
			amount: amount,
			capture: false,
			intent: { stripe: { id: paymentIntent.id } },
			account_id: order.account_id
		})

Ideally swell would add support for the new "payment element" from stripe, since it allows to automatically accept all payment methods of the user's choosing. For example credit card, ACH, apple pay, klarna, affirm, google can all be turned on or off via stripe dashboard.

We wouldn't need to implement them separately when building a custom checkout.

The only challenge, like I mentioned above, is that the payment method is created at the time of payment confirmation, which is unique to the payment element vs card element etc. So the token / payment method data has to be added to swell after the payment is confirmed. It might be possible to have swell-js handle this automatically under the hood. Not totally sure if all the data is available in the client though, it might need a back-end API call to stripe.

Here's the stripe docs describing the differences between the regular card element and payment element: https://stripe.com/docs/payments/payment-element/migration