[alexvilhena]

Hi - we’re Alex, Thiago, and Marcel, founders of Plug (https://www.plugpagamentos.com/). We are live in Brazil, and currently onboarding our first beta customers in the US and LatAm.

Plug is an API to manage multiple payments providers. Through a single integration, businesses can connect to multiple providers and route transactions between them.

It’s hard to know who the right payments provider for your business is. In the early stage you may care most about a fast integration, later you're looking for lower fees and more payment methods, and finally for better acceptance rates and fail-over options. We built Plug so companies could focus on their core business. With our multiple connections, provider-agnostic vault, and routing engine, our users always work with the best provider, on a transaction-by-transaction basis. Working with multiple providers means you can optimize costs and acceptance rates through routing and retries, and that you will be able to avoid lock-ins.

Brazilian merchants in particular change their payment provider frequently. They do this to support multiple local payment methods, to try and improve the worst acceptance rate in Latin America (77% according to Visa), and to reduce their costs, which in some cases can be 10% or more of the transaction.

Alex was at Braintree, Marcel was at Gympass, and Thiago was at Medicinae. We got the idea from seeing our best clients, companies like Uber, AirBnb, and iFood, build their own payment abstraction layers to work with different providers. We've built software that allows any business to do the same: one integration for multiple connections, and the ability to always transact with the best provider without having to write extra code.

Rei do Pitaco has been using Plug to reduce their costs and support multiple payment methods through different providers. CartX has been using Plug to offer multiple providers to their client base without having to integrate each provider. Simplix uses our product to optimize costs by routing to the least expensive provider for each transaction. We're looking forward to hearing your comments!

[arthurcoudouy]

I've got a couple of questions: Do you plan on developing a no-code interface soon? Before learning to code, Stripe on my own landing page was a no-go. Do you help in completing the integration after your own or should I do a proper Stripe integration after Plug?

Congrats on the launch anyway, I'm convinced that your solution makes sense for early stage company. You'll have to provide more value in the future to keep enterprises in the long run I guess.

[alexvilhena]

Hi Arthur - thanks for the questions. Our checkout option is embeddable, but does require coding. We will be releasing payment links, which is essentially a landing page. Might be a good option for your use case. As for the second question, there is no need to complete the Stripe integration after integrating Plug. Once you've integrated our API, you are able to use any payment provider we have integrated. Enterprise companies see a lot of value in the platform actually! It allows them to have their own, provider-agnostic vault, and the increase in acceptance rates through retries and routing significantly impacts their topline. But completely agree that we consistently need to provide more value for all clientes...independent of size :)

[alexvilhena]

feel free to reach out if you have any more questions: [e-mail]

[samstave]

Even in the USA Bodegas have a huge problem with card transaction fees, for example, the one near me charges $.80 per card transaction... So, imagine if you are buying something for $1.60 on your card (Many people do this, especially when you observe them using their unemployment/SNAP (Food Stamps/Government assistance cards)) -- so they pay %50 of the transaction just to swipe their card....

[taurath]

Definitely a market need for this, having built one of those layers myself.

Are you planning to support saved payment methods across multiple providers? Thats always seemed like the touchiest area for me, especially since it would seemingly invalidate a lot of the fraud protection that payment providers use to keep lock-in.

[alexvilhena]

That's awesome that you built that layer yourself. If you're up for it, would love to connect and hear why you did so.

We're PCI compliant so can use saved payment methods across multiple providers, however in our case it does not invalidate the built-in fraud protection that providers use. Additionally, you could also use third party fraud providers at any point within your processing flow.

[taurath]

It was for a big subscription service and we needed to enable a lot of promotional capabilities and also keep payment provider costs low + be able to operationally switch over in high traffic times.

> however in our case it does not invalidate the built-in fraud protection that providers use

Thats pretty neat! Even Stripe Radar? My understanding was that used their client side fingerprinting when the card is inputted, but its been a little bit.

[jbpnoy6fifty]

This space is very red ocean. What makes your product unique than other more mature offerings?

[whoisjuan]

I don’t see how this solution is in a red ocean? Mature offerings where? The only non-Latam alternative that comes to my mind in this space is Checkout.com and that is just partially similar.

A provider routing middleware with the goal of increasing authorization rates is likely not even an attractive business in markets like the US and Europe where you probably can defer to a single payment provider like Stripe for maximum checkout reliability.

This is not the case in Latam. Authorization rates are way lower and anti-fraud heuristics and models by local payment providers are less sophisticated. Most growing business in Latam end up in a situation where they neeed to re-route payments to increase their authorization rates and sometimes in the need to build very strict checkouts that harm conversions but that are needed to avoid a high volume of rejected transactions.

[the_lonely_road]

Could you give us a high level breakdown of your KYC/AML compliance?

[alexvilhena]

Sure! We're actually a software layer. The KYC/AML is done by the providers. We only help our clients ensure this is a smooth process by letting them know the steps beforehand and aggregating all the relevant information before sending through.