How Coord enables real-time payment for parking
At Coord, we think a lot about how to enable a seamless parking experience for our customers’ users. As we built out our Parking API, we faced a number of challenges. One of these was figuring out how to pass payment from an end user to the parking lot operator when the user is buying parking through a 3rd party app. Read on to find out how we solved this and what we learned along the way.
Payments and privacy
When you give an app your credit card number, do you ever wonder where that number gets stored? As a user, you probably don’t want the apps you use to share your credit card number with companies you don’t know. And app developers certainly don’t want to be responsible for figuring out how to store and manage credit card numbers securely.
Enter Stripe. The Payment Card Industry (PCI) has compliance standards that protect users’ credit cards, and most apps delegate the work of complying with these rules to companies like Stripe.
What this means is that the app developer never sees the credit card number in the first place — it goes directly to Stripe. Within the app, the user inputs credit card data into a Stripe form input. The app then sends the card directly to the Stripe API. In return, the app gets a token representing the credit card data that they can use to charge the user. Using Stripe has allowed us to delegate the hard, payment-related work and focus on bringing the best parking experience possible to our customers’ users.
We like using Stripe a lot, but it’s important to mention that they aren’t the only company that can do this. Other payment processors comply with the exact same regulations, and perform the same security functions. The system that we’re describing relies on the general mechanics of payment processing more than any one company.
Tokenization and why it matters
Because we don’t want to store or send the user’s credit card number, we instead use a placeholder called a token. Tokenization is the process of taking sensitive data and turning it into a set of characters that have no extrinsic value, but map to the underlying, sensitive data. This transformation only works one way — you can create a token out of a credit card number, but you can’t extract the original credit card number from that token. To charge the underlying credit card, you send the token back to Stripe.
Not everyone can use the token — otherwise it would be just as sensitive as the credit card number itself. Instead, token issuers need a way of validating that the entity using the token is allowed to do so. Stripe handles this with account linking. The token’s creator gets to decide which merchants (accounts) are able to charge the token. More on this later.
Stripe utilizes tokenization to prevent apps from having to deal directly with credit card information. With a valid Stripe token, you can do one of two things: create a one-time charge on that credit card, or create a Stripe customer to perform recurring charges on. Either way, the app never has to store the credit card information and only has to resend it if there’s a change in any of the data.
Payment processing in a many-to-many marketplace
If a parking operator just wanted a purchasing flow for their users to buy parking within their app, they’d be all set using Stripe (or another payment processor) directly. But we wanted to enable this feature for multiple parking operators and multiple apps in a many-to-many marketplace. Without us, customers would have to create a new Stripe account for every single parking lot operator they work with and the parking lot operators would have to make a Stripe account for every app. Instead, we have parking lot operators create a single Stripe account to accept payments, and we create a special Stripe account for the app that’s housed under our master Coord account. We then connect all of these accounts to each other so that any app can pay any parking lot. Down the line, this makes it possible for us to connect multiple demand-side apps to multiple supply-side operators, all without seeing a single credit card number.
To dive a little deeper, here’s an example:
We create a Coord-managed Stripe platform account called Coord-${app} representing the demand-side customer. We then link the account to the parking lot operator’s account. This lets us re-tokenize a single Stripe customer for use across several connected accounts, meaning we can give a parking lot permission to charge a user who comes from the app.
Before the end user starts a parking session, the app sends the user’s tokenized credit card information (created using the credit card data and the Coord-${app} public key) to our backend. We use that token to create a Stripe customer, whose ID we store in our database. When the user pays for parking, we ask Stripe to create a new token for the parking lot operator based on this customer ID. Because we linked their Stripe account, they can use that Stripe token to charge the user for parking.
This is a repeatable process for any number of parking lots an app wants to integrate with. We simply have to link the parking lot operator’s Stripe account, and when an end user starts a session with that parking lot, we re-tokenize the Stripe customer and send the token to the parking lot operator for consumption.
Now, say we wanted to add a new parking lot operator to the app. We’d start by having the operator create a new Stripe account (or create it for them) and link it to the app’s current Stripe account. That’s it — and none of it requires any changes on the app’s side.
This model also has applications beyond our Parking API. As we expand our offerings to allow for transactions across multiple forms of mobility, we’re excited to be able to apply our Stripe model to support many-to-many marketplaces for other mobility services as well.
Secure, many-to-many payments are a key part of Coord’s mobility platform. By using Stripe to handle compliance and risk, we can focus our efforts on providing the best experience and seamless integrations for our partners. If you have had similar experiences or have comments on the way we structured our integration, we’d love to hear from you! Please chat with us on coord.co.
