 Stripe JavaScript Library. Please go ahead. I'll go ahead and share my screen. Let's see. Okay. All right. Do you see the first style of page? Is that what you're seeing? Yes, we can see. Perfect. Okay. So hi everybody. My name is Akita and I work for Stripe. I'm going to quickly talk about the Stripe JS library and how we decide to abstract the complexities in our APIs. So before we talk about how Stripe abstracts away complexities, I just quickly let you touch upon what Stripe does. We provide payments APIs and a lot of different solutions for businesses to go online. This includes not just payments but also fraud detection and other adjacent tools that help businesses operate online fundamentally. Now, there are a lot of complexities of processing payments and there is the seller and then you have to worry about all these different cards. You have to then think about what are the compliance that you need to meet with online businesses, some other things like how do you run your analytics, how do you detect fraud. And then finally, you have to think about every new country and every new country's currency and the nuances that every country has. And so thankfully Stripe handles most of this for you so that customers can actually focus on just integrating with these payment methods by sort of abstracting away all of these different concerns behind the hood. So very recently, well, maybe not so recently around like Q4 of last year, we launched in Malaysia and this was sort of a big event for us and one of the things that happened while we were planning to go into Malaysia as like a full-fledged release in Malaysia, we realized that one of the payment methods that we need to offer is FBX. FBX is a very Malaysian specific payment method that's actually equally popular to cards and we decided to understand what FBX was about. And so FBX is nothing but like sort of a synchronous method in which buyers and sellers can exchange payment information without buyers having to provide credit, any kind of credit card information or even bank account numbers. So it's a bank-based redirect method where, you know, in step one, like there's about six steps that, you know, I took from the FBX docs themselves. You click on FBX, show in a bank that you would like to transact with. Once you collect, once it's like the bank that you want to transact with, you are redirected directly to the banks page. Since in the post context, I would be like looking at OCBC or DBS page, you log into these banks and then once you log into the bank, you can basically accept or reject the transaction and assuming that you, you know, click on one of the buttons, you're redirected back to the merchant side. So let's quickly see a demo. I am going to switch tabs, so let me know if you can see this tab. Joe, can you tell me if you're seeing a sort of a demo? Is that what you're seeing? Yes, you can see FBX Bank. Awesome. Okay, great. So this is what the flow looks like in reality and I'm using this flow powered by Stripe, of course. And so basically when you click on, it's a localized element, which is responsive. So, you know, works with both mobile and web views. It has the bank icons. And then it has this like wording called Luar Talyan, which basically means the bank is offline. And this is real-time data that people pull about banks. You can click on a particular bank that you want to transact with and then pay, you know, Malaysian ring in 50.99. And when you decide to pay, it basically takes you to the Stripe test page because I'm doing this transaction in test mode. And then you can authorize the test payment and you'd be redirected back to the original page. My sandbox is initializing, but either way, you'll get redirected back. So in interest of time, I'm going to go back into the slides. And let's see. Just a second. Okay, cool. So now, you know, Stripe generally tries to make the entire experience easy. It makes onboarding super simple for merchants to get started immediately with using payment methods. You just saw the test page that we had. And this test page is generally what we offer for most copy and methods, where you can actually, you know, instead of going through all these complex flows of getting redirected to a real bank, you get redirected to Stripe's test page. You can authorize or reject and you can see how that behaves. And then we have very detailed documentation that details how our APIs behave, how the various error codes work out. And so all of that is, you know, is aimed at making API integration extremely simple. But you know, even if API integration is simple, integrating with, you know, the backend part of it is not always easy and trivial. And so this is where, you know, things can get complicated and integrating with the FPX UI that I just showed you was involved a bunch of different things. So for instance, you can think as a front-end developer, you need to, if you had to, if you were given a set of FPX APIs and now you had to create the UI, you basically would go about looking at the scheme and understanding which other banks that are offered, identifying what are the logos for each of these banks, making sure that you have the right size of logos, you know, the offline element that we showed where you can actually pull real-time data. That's something that you would have to integrate with if you wanted that. You'd have to make your element responsive, add localization and all of those concerns. So I think the point here is that there is still a lot of effort involved in trying to make the, you know, in trying to just work on the UI side of things. And so this is where Stripe comes in and Stripe elements come in, and Stripe elements are Stripe's pre-built user, you know, UI components that automatically handle complex user flows, such as displaying the entire UI, making it responsive, handling redirects for users. And so with the FBX launch, we also added an FBX element to handle the entire flow. So what I just showed you in the demo was actually built using an FBX element rather than building the UI from scratch. So there are five steps to get started with FBX. And, you know, we'll go through the code in each of these five steps very, very quickly. The first step is to load the Stripe.js library. Once, you know, you load the Stripe.js library, you do an instance of Stripe, and then you can pass in your public key to the Stripe instance, as well as pass in a bunch of options that we'll talk about. Using this instance, you can call a method called Stripe elements, and this creates an instance of elements itself that, you know, using the Stripe instance that you created in the previous step. So you basically call a method on the Stripe instance. In step three, you basically use that element, whatever was returned to you by that function, and you, you know, end up calling another method called create. And in this case, I'm passing the create option called FBX Bank, which is basically telling Stripe.js to create the FBX element, and then also passing in a bunch of different options, such as custom fonts, et cetera, that we'd like to use with this element. Finally, we want to make sure that the element actually appears in the user screen, and this is where we call the mount function on the element that was created in the previous step, and this is the step that makes sure that now you have a fully functional UI that appears on your checkout page. And so with this step, you already start seeing the UI that we just saw, and then finally, you know, you can call a method which then handles the payment side of things, which is basically calling confirm FBX payment, passing in the element that was just created, and this is the one which is basically responsible for talking to Stripe servers, and so I've just basically taken the UI to the next step to actually do the API integration. And so that's it. You know, in these five steps, we already sort of have, you know, the entire flow built out. And, you know, while, you know, from a top-level perspective, this seems interesting, and it feels very developer-friendly, but I guess, like, you know, it's also natural for us to question what's going on under the hood, and so now we're going to talk about what each step actually does under the hood. And so in the first step, we load the Stripe.js library. When Stripe.js is basically loaded, or rather when you, you know, a global variable is created and it's added to the window. And then you may also notice how we pass in a bunch of options to Stripe.js. So there's betas as an option, and what betas does is we'd like to control our beta features, and FBX is no longer in beta. It's public, but when it was beta, we wanted to control users from basically, like, we wanted to make users aware that this is not something that we have publicly released, and hence it's subject to changes. And so the beta flag is what attaches methods such as confirm FBX payments. So remember, we saw confirm FBX payments in step five. So the betas that get passed in, they map directly to which methods get attached to the Stripe instance. And so based on the beta that a user passes in, that's the sort of, you know, instance that they get with all the right methods included in that. And then finally, you know, initializing Stripe.js with your public key creates this thing called control of frames. So just as a background, you know, we are going to talk about a bunch of, like, iframe-related things in this talk, because Stripe.js is built on a lot of iframes. And the background for that is that Stripe.js' initial motivation was to handle credit cards. And as you know, the credit cards are subject to a bunch of compliance where as merchants, you know, there is a certain expectation of how credit card numbers are handled because this is sensitive information. And so Stripe.js was meant to not let the merchants ever be able to touch this information and instead, like, keep all of this information within the iframe, as well as, you know, do all the server interactions to Stripe servers using it from the iframe itself. And so all of this iframe's sort of like magic makes it possible for merchants to just use Stripe.js and never worry about PCI compliance. And so that's also one sort of contraction that Stripe.js gives you. So among the many roles played by the controller frame, it coordinates the creation and removal of other frames. And why do we have other frames? We'll also see in the next few steps. But essentially, you can, you know, imagine that at this point, the minute strike is initialized, a controller frame gets appended to the DOM and it has a separate app that's running inside it and this app keeps track of other iframes and coordinates amongst other iframes that get created in the subsequent steps. In the second step, as you remember from the code, we initialize a new instance of Stripe elements. So what happens at this point? You know, basically the user can choose to specify locales and fonts at this step and these fonts will be fetched asynchronously. So before the UI even appears on the page, the Stripe.js will look at these list of fonts and start loading them from wherever the fonts are hosted. And so in a way, it's doing some kind of optimization to make sure that the load time is faster. In step three, we end up having elements.create, which creates a new instance of the FBX bank element itself. And so at this point, if you remember that, you know, in the first step when we were initializing Stripe.js, we passed in betas as an option. And so we perform a bunch of validations here where we make sure that, you know, if, let's say, FBX was in beta still, then, you know, if a user is creating an element called FBX Bank, they also had passed in the right set of betas before. Like, let's say if there was a typo here and instead of FBX Bank, the user said FBX, then we also flagged that out as like a mismatch. And it's important for these names to match because FBX Bank directly tells Stripe.js what kind of UI is the user expecting. And if you change that value with something else that's valid, like maybe card, then you will see the card UI appear in front of you. So basically a bunch of validations happen in this step. If all the validations pass, that's when the controller app ends up creating multiple iframes. And so each of these iframes end up having, you know, their own little mini apps running within them. These iframes are basically one of them is the primary iframe. And so it's like the main iframe. And then you have secondary iframe. And it really depends on the use case of the payment method, whether you need multiple iframes or if it's okay to do just one. And for FBX, we did use like two iframes that I can explain to you why we use two iframes for just the UI purposes itself. So at this step, also like the styles that are passed into the iframe are basically applied onto the actual style attribute. So that basically makes sure that the styles are set correctly on the UI elements that the iframe ends up rendering. So the controller app keeps track of these iframes. So you can see that it has like a little variable or state that it maintains, which actually keeps track of which iframes are present. And then, you know, looking at this UI, what we just saw in the demo, that was actually a combination of two different iframes. And so there's like the primary iframe, which is the select bank dropdown. And then there's the secondary iframe, which is the actual list of the banks. And the reason these are two separate iframes is because when a user loads an iframe on their website, they would most likely load it as just the select bank. So that means the dropdown is shut at that point. And so you don't want to have a situation where when the user clicks on the select bank dropdown, the iframe suddenly expands. And that expansion like increases the height of the iframe itself, shifts all the elements of the form underneath it. And you know, like sort of creates this like a really weird user experience. And so the way we handle that is that we create two different iframes. The second iframe which has a list of banks is actually hidden. And then, you know, when the user clicks on the select bank dropdown, the first primary iframe communicates to the secondary iframe using post message API. And this is where the secondary iframe, containing the actual list of bank appears and stops being hidden anymore. The other thing that happens here is that there's also this offline bank information that we try to show. And this information is fetched by the primary frame by contacting api.strike.com, getting all the offline banks, and then passing that as a message to the secondary frame so that when the secondary frame opens, it already has that information available to it. So that's kind of like what happens at this step. In the fourth step, you know, we still don't see any UI. And at this point, we still need to add the amount that entire, you know, iframe that was created in the previous step into the user's page. And so this is where the amount step comes into play. Finally, you know, at this point, we will see the UI and then this is where the user can actually click on, hey, I'd like to pay with FBX. And this is where the entire redirect logic comes in. So confirm FBX payment actually takes care of extracting. Basically, you pass in the element itself and what it does is that it uses the element. It tracks the information of which bank was selected by the user from the element. Passes this information to Stripe Servers. And then Stripe Servers will basically use this. I mean, it's just like an API call at that point. And Stripe Servers will then decide where to redirect the users to, you know, so that's at that point, the payment is complete. And that's basically where we saw the redirect and then coming back to the original merchant site. All of that is handled within confirm FBX payment. So what I just explained in the last few slides is also relevant Stripe Samples. So feel free to, you know, take a look at Stripe Samples, download some of these samples and then use them for your integration. That's something that you're trying. And so some, I mean, I try to go really fast over these, but some of the key takeaways are that there is, we're trying to extract complexity where it's possible by basically handling a lot of things like PCI compliance, handling things like the UI for, you know, UI for complex payment method interactions for our users. And so that's that's one part of, you know, how we try to make our API integrations a lot more friendlier. The other bit is about reducing the unknowns in our APIs. And so basically, we focus a lot on making sure that certain error cases, such as if a bank is offline, what really happens, all of this is something that is present in our documentation. And you can also try this entire like error scenario in using our test mode transaction. So we try to like make it as predictable as possible about as to what would happen in your production integration. And then related to the second point is that we do focus a lot on the test environment, just because it, you know, payments actually involve movement of money. And that's not something that, you know, you can keep trying and failing at. And that's where the test environment gives you guarantees that the money will not be moved, but you will get a close enough experience of what the real flow would look like. So yeah, basically, you know, if there are, FBX is just one of the payment methods that we worked on and there are many more to come. So if you're interested in what we did in Striped Shares or interested in working with similar problems or how we sort of think about working on these new integrations, I'd be happy to chat more. Thank you. Thanks very much for your talk. We can open it up for questions if anyone has any questions. We started using Striped this year, but we didn't use iFrames, we just direct, we use the library and it directs your website and then the website when the payments finished, it comes back to us. Right, so it's without using the Striped JS, but like using the API, like API clients, is that material? Yeah, I think we use the library to set up to get the key or something and then we redirect it using that. Yeah, that makes sense. I mean, I think it all depends on what sort of resource constraints that folks have or what kind of sophistication that folks have. And I think Striped JS is like aimed at giving this sort of best of both worlds where there is, just because you can pass in your own styles to the element, you can customize it to look the way your recipe or website looks. It doesn't stand out, but at the same time it reduces the amount of effort. But we've also seen sufficient number of cases where users like even more control and so they go directly with the API integration and so there's like all these different parts that are open. Any questions from the chat room? If you don't want to ask out loud, you can also just type it on the chat room. Okay, so, well, I guess we move on to... If you want to ask and give you any questions in the future, you can find her on Twitter. Is that your preference? Yeah, so Twitter works. Okay, so now we can move on to open announcements. Thank you.