PAYMENT PROCESSING FOR PLATFORMS & MARKETPLACES

The Starting Point

In a typical online store, money flows from a customer to a merchant. On an ordering platform, three parties are involved in every payment: the person placing the order, the restaurant providing the service, and the platform facilitating the transaction.

This raises a question that must be answered before writing a single line of code: Where does the money go between payment and disbursement, and who is responsible for it?

Why not just open a merchant account?

The obvious approach ‒ where the platform collects all payments into its own account and transfers the restaurants’ share to them ‒ is more complicated than it seems. Anyone who consistently accepts money that rightfully belongs to others is operating in the realm of regulated financial services. Added to this is the day-to-day operation: settling accounts for each business, making transfers, handling receipts, and reconciling discrepancies when questions arise.

EAT-TAXI uses Stripe Connect

Stripe Connect is designed specifically for this scenario. Here’s how it works: The platform serves as the technical and commercial framework, but each service provider gets its own account with the payment service provider that’s linked to the platform. 

Stripe is one of the world’s leading payment providers. Our team has already successfully implemented Stripe in various projects.

The Structure of EAT-TAXI

In this structure, EAT-TAXI serves as the platform. Each participating restaurant has its own linked account.

This has three specific consequences:

• Restaurants are onboarding through Stripe

  Company information, proof of identity, and bank account details are recorded and verified there ‒ the payment service provider, not the platform, handles the legally required identity verification. 

• Each payment is assigned to a specific account

  An order placed at Restaurant A goes directly into Restaurant A’s account, with the platform’s share deducted. There is no shared pool that needs to be divided up later.

• Stripe manages the payouts

  They are deposited according to a fixed schedule into the business’s registered bank account. At EAT-TAXI, no one initiates transfers or maintains payout lists.

For restaurants, this means predictable amounts at predictable times. For the platform, it means that administrative overhead does not increase with the number of affiliated businesses. The fiftieth restaurant requires the same amount of effort as the fifth.

Payment

Every order generates a payment transaction ‒ known as a “Payment Intent” in Stripe terminology. This transaction has a status ‒ it is awaiting confirmation, fails, or completes successfully ‒ and this status serves as the primary indicator for the entire order processing workflow.

Payment is made directly at the time of ordering. This means the order isn’t sent to the kitchen until payment is confirmed. The restaurant does not need to check whether payment is ultimately made. If necessary, however, participating restaurants can also allow cash payments. These are then immediately marked as confirmed but remain open in the system, so that the driver or the restaurant is informed which customers still have a cash payment pending on-site.

A Variety of Payment Methods

At launch, EAT-TAXI will accept credit cards, PayPal, Klarna, Amazon Pay, Google Pay, Apple Pay, and cash.

All payment methods run through the same technical system, the Stripe Connect API. Additional payment methods can be easily activated with a single click in the Stripe Management Board. This gives our client, EAT-TAXI, flexibility and allows them to quickly take advantage of new, popular payment methods.

Cash payments are, in a sense, a special case and technically the most interesting: Here, a complete order is processed without a real payment transaction ever taking place on the service provider’s end. Order processing must therefore not depend on the payment status but must account for both scenarios. For a platform operating locally, this is a critical consideration.

Less than one second per payment transaction

By using Stripe’s Payment Intent model, a payment in the EAT-TAXI app takes only about half a second on average ‒ measured from the user’s confirmation to the feedback in the app.

This is more than just a footnote for three reasons. First, checkout is the point where orders are abandoned: Users who wait without knowing what they’re waiting for will close the app. Second, it’s precisely this wait time that leads to the most frustrating errors ‒ users retype, swipe back, reload the page, and so on. The shorter the process, the less likely this situation is to occur in the first place. And third, the order reaches the kitchen sooner. With a delivery time that’s already tight, every step that doesn’t involve waiting counts.

Strong Customer Authentication

In Europe, online payments are subject to strong customer authentication requirements ‒ for example, a verification prompt via a banking app or authentication through PayPal and similar services. Stripe handles this verification process and applies the permitted exceptions, such as for small amounts. For integration, this means above all that the checkout process must accommodate an intermediate step in which the user does not have to leave the app but can complete everything conveniently within a single interface.

What We Tested Before Launch

In Stripe's test environment, you can simulate the scenarios that are rare in production ‒ and are precisely for that reason particularly troublesome: declined cards, failed authentication, duplicate event notifications, connection interruptions during confirmation, and cash payments for orders that have been modified in the meantime. Each of these scenarios was tested once before the first live payment was processed.