#Mollie Checkout + Connect coming from Stripe

1 messages · Page 1 of 1 (latest)

hexed flame
#

I'm looking at adding a Mollie integration to a Ruby app. We currently use Stripe Checkout with Stripe Connect, so I'm coming at it with ideas based on how they do things (😅)

I've been browsing the docs and can't seem to find answers to the following (maybe just missed them...) - could anyone help me out with answers or pointers?

1 - How would I create a Checkout Session on behalf of a Connected Account and redirect a customer to it? (In Stripe we have javascript embedded on a frontend page that dictates the connected account id used - we then ajax to the backend to create a session and retrieve its url)

2 - Are webhooks fired at different stages of a Checkout Session? E.g. upon completion or expiration?

3 - Does completion of a Mollie Checkout Session result in creation of a Customer object, Payment and/or Subscription, as applicable? (In Stripe, we get an Intent object we use to create a fully-fledged payment/subscription via subsequent API calls)

4 - Any examples of webhook structure for different resources/events?

5 - Not strictly a dev question but I also wanted to know: are there any fees for refunds or chargebacks, specifically with regard to SEPA direct debits?

eternal path
#

Hi @hexed flame,

  1. This depends whether you want to become a Marketplace or a Platform (https://docs.mollie.com/docs/connect-overview). The checkout URL has to be created by your backend. The response of createPayment/getPayment (https://docs.mollie.com/reference/payments-api) includes the Checout URL at _link.checkout.href.

  2. The webhook is called on the following stages in the paymentsAPI: paid, authorized, expired, failed, canceled, a refund is created (processing, refunded, failed) or a chargeback is received. If you use the orders-API (which I wouldn't integrate anymore because it will become deprecated in the future), it also fires a webhook on creating a shipment, when the order ( or a lineitem) is canceled or refunded.
    https://docs.mollie.com/reference/webhooks

  3. No. Not directly. It depends on the created payment. Generally, customers must be created manually before a payment is created (if you want to; you don't need to at oneoff-Payments). When you want to create a recurring payment, you must set recurringType to first. The the response will include a valid mandate (after successful payment, I guess). Paypal is a little bit more difficult, there I'm not 100% into it. https://docs.mollie.com/reference/payments-api / https://docs.mollie.com/docs/payment-methods

  4. The webhook only includes the id-Field of the ressource, that changed. with the first part of the id (like tr_ for transaction) you can identify which type of ressource changed and than you can GET the ressource via API to see the new Resource.
    https://docs.mollie.com/reference/webhooks

  5. Yes. For me (I guess that are the normal fees) are the following at SEPA Direct Debit:

hexed flame
#

Hi @eternal path, thank you so much for your response! This goes a long way towards getting my head around how Mollie works!

The only thing I'm still unsure of re: the above is how to authenticate API calls on behalf of connected accounts... We'd be a Platform rather than a Marketplace, and would use OAuth to acquire Access Tokens for each organization. The docs have Ruby code examples that start by configuring the Mollie::Client with an api_key like this:

Mollie::Client.configure do |config|
  config.api_key = 'live_1A2B3C4D...'
end

It doesn't say explicitly that access tokens are interchangeable with API keys in this context, but I guess we'd just need to re-configure the Client each time we're about to do something and set config.api_key to the current org's access token.

eternal path
hexed flame
eternal path