Stripe SCA support

[benjaoming]

Background

New EU legislation means that online card payment has to go through the issuer's 2FA. This is known as "Strong Customer Authentication". Some background here: https://support.stripe.com/questions/strong-customer-authentication-sca-enforcement-date

Solution

AFAIK, in order to process payments for fundraising, Django needs to use newer API and patterns offered by Stripe. I have an existing implementation to refer to.

Firstly, a checkout session is created and the user goes through Stripe's pages for payments. This is almost the same as before, except there is no modal popup on the shop's own site, but you to through a branded Stripe page.

Following this, the main change is that now the backend processes the payment through an async callback to a webhook which it receives from Stripe.

In the frontend, the user is redirected to a custom success/failure page. But AFAIK, this page has to be generic because it cannot assume that the payment is successful until the webhook is called.

Here is an implementation of a webhook that processes the successful session:

import stripe
# ...

def stripe_config(currency):
    """
    Sets configuration of stripe module according to the currency that we are
    using - if for instance you have a Stripe account for Euro payments and
    one for Dollar payments
    """
    config = settings.STRIPE[currency]

    if settings.DEBUG:
        stripe.api_key = config["api_key_test"]
    else:
        stripe.api_key = config["api_key"]

    return config


@csrf_exempt
def stripe_callback(request, currency):
    """
    Handle callbacks from Stripe, for instance /payment/stripe/webhook/usd/
    """

    payload = request.body
    sig_header = request.META["HTTP_STRIPE_SIGNATURE"]
    event = None

    # Call stripe_config - in case 
    config = stripe_config(currency)

    try:
        # Notice that the endpoint itself has a secret known only to the endpoint and Stripe!
        event = stripe.Webhook.construct_event(
            payload, sig_header, config["endpoint_secret"]
        )
    except ValueError:
        # Invalid payload
        return HttpResponse(status=400)
    except stripe.error.SignatureVerificationError:
        # Invalid signature
        return HttpResponse(status=400)

    # Handle the checkout.session.completed event
    if event["type"] == "checkout.session.completed":
        session = event["data"]["object"]

        # Activate original language of this session
        if "metadata" in session and "language" in session["metadata"]:
            translation.activate(session["metadata"]["language"])

        if settings.DEBUG:
            order_id = 123
        else:
            # In this example, we stored an order ID with the payment
            order_id = session["client_reference_id"]

        order = models.Order.objects.get(pk=order_id)

        # Create a payment object with information from the Stripe session and
        # mark the order as paid, then notify customer and admins.
        try:
            payment = models.Payment.from_order(order)
            payment.stripe_session_id = session["id"]
            payment.save()
            order.is_paid = True
            order.save()

            # Inform admins
            mail_admins("Card payment success", "Payment ID: {}".format(payment.pk))

            # Inform customer
            m = mail.PaymentCreateMail(
                request, payment=payment, to=[payment.order.email]
            )
            m.send()

        except Exception as e:
            # The card has been declined
            mail_admins("Card payment err", str(e))
            raise

    else:
        mail_admins("Card payment unknown payload", str(event))

    return HttpResponse(status=200)

Reference

• Creating a checkout session: https://stripe.com/docs/payments/accept-a-payment
• Webhooks: https://stripe.com/docs/payments/handling-payment-events

[carltongibson]

Hi @benjaoming Thanks for this! I will take a proper look tomorrow.

[carltongibson]

Hey @benjaoming — Thanks again here. It's very clear. I shall have a pop at it and ping you when it doesn't work. 😉

[carltongibson]

Ok, post Thursday update.

We need a slight update to the flow we're using. We'll use the new hosted checkout page. That'll let us use the Portal for managing subscriptions too, which is less code for us.

I'll potter over the weekend and finish next week now.

[carltongibson]

Part 1 is #1058 — main donation page.

I'll follow-up shortly updating the backend Manage your donations page.

Finally I'll cleanup and update the Stripe API version to latest and so on.

[carltongibson]

Note to self: I can add max value validator to the donation form (for silly values, which Sentry occasionally reports).

[sentry-io]

Sentry issue: DJANGOPROJECTCOM-EW

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[MarkusH]

/unstale

[carltongibson]

@cgl This was the holding issue for the Stripe updates we were discussing at DjangoCon.

Basically, we'd like to use the Stripe hosted portal, and then remove the direct API integration code, closing the related issues (We have OK from the board for that, and things like privacy policy and T&C to add to the site and all that Jazz — but we ran out of steam into 🦠 ...)

[cgl]

Hey @carltongibson thanks for pointing out. I can work on it. Is there any draft work I should be aware of other than the merged PR? I will have a better look later.

[carltongibson]

Hey @cgl.

Right, yes... 😜 — I got to a certain point with this implementing the Stripe portal, and then we needed Privacy Policy and such, which I got drafts for some time later, but never got back to.

• You'll need access to Stripe. (I'll email ref that.)
• Then the first pass is to redirect from the Hero page (≈"Manage your donation") to the Portal, and let folks use that. (I have a very minimal sketch of this I can send you.)
• Then it would be good to tie the Hero page into actual user accounts, rather than just unique URLs, so they can manage "profile" details, such as logo and such. This ties into Add an FAQ about changing a recurration donation #775 and more recently Improvements to the Corporate Sponsor Experience #1171 — it's about helping corporate sponsors see the value in backing the DSF.

I think first pass would be get a feel for how it is, and then a sketch of a plan for the later bits before necessarily coding too much is a good idea. But launching the Stripe session for the portal isn't too hard — you just need the customer ID — so that first part should be doable. (I recall thinking I wasn't that far away...)

Thanks for the interest here. It's precisely one of those areas where there's lots of ideas, but a real need for somebody to lead the effort 🎁