A Pagar.me checkout in React Native splits into a card screen, a CPF and phone screen, a CEP address screen, the payment endpoint and a persisted auth token. Build the form with Formik, keep the price server-side, and keep the API key out of the app.
Pagar.me checkout in React Native: how the flow works
A Pagar.me checkout in React Native is a five-screen flow: collect CPF and phone, collect a billing address with CEP autofill, collect card data, post it to your backend, and store the payment status on the user. The 2020 Dev doido series built exactly that chain, and its structure still fits the current API.
Pagar.me, operated by PagBank, is a Brazilian payment gateway and merchant acquirer covering credit card charges, capture, refund, recurring payments and gateway-level tokenization, according to its integration guide. Which API version a given account uses depends on the merchant setup, and that account-level detail is where most of the work is.
The tutorial ran on React Native with Formik and Yup for forms, Redux Saga for the profile update, cep-promise for address lookup, and the community package react-native-credit-card-input for the card widget. Two pieces of the transcript matter in 2026 because neither is spelled out in the video: the shared secret and the card data path.
Card data must go from the phone to your server encrypted, because anything typed into a React Native form lives in JavaScript memory and in any request that leaves the device. The tutorial encrypted the card object with crypto-js and a key hard-coded in the app, which is a demo shortcut and not a production control.
What the 2020 build got right and where it aged
The visual and state design of the series still applies, but several of its mechanics are dated: React Navigation 4, a card widget tied to a test key, and a hard-coded encryption secret all predate current practice. The five-screen structure is the part worth copying.
The series is the work of Dev doido, the channel persona who recorded the 37-minute episode on 15 June 2020 as part of a longer React Native and Node teaching sequence. The jokes about Faustão, Craque Neto and Zeca Camargo are part of the format, and the code is the substance.
That React Native 0.61-class setup used React Navigation 4, the era's Formik and Yup versions, and the react-native-credit-card-input library for the animated card. None of those choices is wrong in 2026, but a new project should expect a different navigation library and dated dependency versions.
The account-level mechanics changed more slowly than the screens. Pagar.me documents SDKs for Node/TypeScript, Python, PHP, Ruby, Java, .NET Standard and Go, generated from the Core API v5 specification, according to the APIs.io provider entry. A 2026 integration therefore starts from the Core API v5 endpoints rather than the 2020 wrapper calls.
Splitting the checkout across React Native and Node
React Native owns three jobs in this architecture: validate CPF and phone, resolve the CEP to a street address, and capture card number, expiry, CVV and holder name. Your Node backend owns the fourth: sending the encrypted payload to Pagar.me with the API key that never reaches the app.
The tutorial created three screens under a payments folder: one for registration completion, one for the billing address, and one for the card. A home screen and a payment route completed the flow, with navigation based on whether the cached user already had a CPF.
The CPF and phone screen used Formik and Yup with a 14-character CPF mask and a full phone length, then called a Redux Saga action with the raw phone and a formatted CPF. That split was intentional: Pagar.me wants digits for the tax ID, while the form shows punctuation for the user.
The address screen used a nine-character CEP mask and called cep-promise on submit, filling street, district, city and state from the response. The card screen then received all of it through navigation parameters and posted one object to the backend.
Implementing the form and card state
Formik and Yup carry the validation, and a single submit handler assembles the payload, so the card screen needs only three pieces of local state: the credit card input value, the ciphertext, and the pending user. Splitting validation from submission keeps both testable.
The tutorial's CPF check stripped the mask with two replace calls before running a digit-level validation function, then left the form only when the result was true. Guards like that belong in the submit handler as well as in the schema, because a masked field can pass a length check with the wrong characters.
A Yup schema for the card screen should validate the number by removing spaces first, then checking length and checksum, and validate expiry against a format your backend understands. The 2020 episode hit a real bug here: the expiry month arrived without a leading zero, so a single-digit month failed on the wire.
For the widget, the react-native-credit-card-input component exposes display fields such as the card number, holder name, expiry month and expiry year, plus a card-valid flag. Binding those to local state gives you the animated card and the validation flag at once.
Handling CPF, CEP and phone without breaking on edge cases
CPF, CEP and phone are the three fields most likely to break a Brazilian checkout, and each needs one canonical format for storage and one readable format for display. Store digits in state, format in the mask, and normalize again before the network call.
The tutorial's 55-country-code prefix is a display convenience for the phone field, and it is worth keeping only if the backend expects the same value. International numbers and landlines should be an explicit decision rather than a prefix assumed by the form.
CEP lookup should fail softly. When cep-promise found no address, the tutorial alerted the user and left the form editable, which is the right behavior: the address belongs to the customer, and autofill is a convenience.
Comparing the 2020 build with a 2026 implementation
The table below compares the tutorial's choices with what a new Pagar.me integration should assume in 2026, based on the vendor's current documentation and the Core API v5 SDK listing. Where a row says the tutorial is dated, that reflects a specific library or shortcut, not the overall design.
| Concern | 2020 Dev doido tutorial | 2026 starting point |
|---|---|---|
| Navigation | React Navigation 4 | Current React Navigation release |
| Card input | react-native-credit-card-input | Maintained card widget or custom fields |
| Encryption | crypto-js with an app-side key | Server-side encryption or tokenization |
| API surface | Wrapper calls used at the time | Core API v5 endpoints |
| SDK support | Not used | Generated SDKs for eight languages |
| Auth persistence | Token stored after payment | Store and rotate tokens deliberately |
The most important row is encryption. Encrypting on the device with a key the app also carries protects the payload in transit from casual inspection but not from someone who extracts the key from the bundle. Server-side encryption or gateway tokenization is the safer default.
Pricing, test keys and the production switch
The tutorial hard-coded a 30 BRL price and a test key, which is fine for a demo and wrong for production: pricing belongs on the server, and a live key must never ship inside a React Native bundle. Treat both values as server configuration after the prototype.
The 2020 episode confirmed payment in the Pagar.me test environment with a test card, then verified the response in Reactotron. The screen also granted a paid state and a 30-day window, after which the user would be prompted again. That status check ran on the home screen and again in the submit handler.
FAQ
- Do I need the Pagar.me API key inside the React Native app? No. Send the payment request to your own backend, which holds the key and calls Pagar.me. Keeping the key in server configuration also lets you rotate it without shipping a new app build.
- Is encrypting card data in the app with crypto-js safe? It is better than plain text but not a substitute for server-side protection, because a key bundled in the app can be extracted. Encrypt on the server or use the gateway's tokenization for card storage.
- How should CPF be validated and formatted? Validate the digits with a checksum function, Stripe punctuation before sending, and keep the 14-character mask for display. The 2020 tutorial used exactly that split between the form and the request payload.
- What replaces the 2020 navigation and form libraries? Use a current React Navigation release and current Formik and Yup versions, and check that the card widget you choose is still maintained. The flow logic of the tutorial does not depend on those versions.
- When should the app show the card screen? After the profile has a CPF and phone and the address is confirmed. Gate the card screen on that profile state so a returning user with a valid plan skips the registration steps.
- What does Pagar.me's Core API v5 cover? The v5 API supports charges with capture, cancellation, refund, item-level pricing and subscriptions, per the provider listing, and its webhooks notify on events such as order.paid and charge.refunded. Read the webhooks overview before wiring status updates.
- How should the paid state be stored? Save the plan status and expiry on the server and read it at app start. The tutorial's 30-day check worked, but a client-side clock comparison is easy to bypass.
- Why did the expiry month fail in the tutorial? The widget returned a single-digit month, and the code concatenated it without a leading zero. Normalize the month to two characters before building the payload.
- Which Pagar.me integration path fits a small app? An e-commerce platform plugin or an SDK is the shortest route, and the integration guide covers partner platforms when you do not want to own the checkout logic.
Turning the checkout lesson into written content
The checkout in this build survives because someone recorded the decisions, the failed expiry month, and the refactor that fixed it, not because the code was elegant. That kind of walkthrough holds more value than a polished tutorial written after the fact.
From Video to Article with Skala blog
The recording method behind this walkthrough is the same one that turns raw teaching into something searchable: show the mistake, explain the fix, and keep the reasoning around the code. If you already explain that kind of work on video, the explanation is the asset.
With Skala blog, you paste a YouTube URL, the video is transcribed, and an article draft comes back ready for your edit. Builders such as Dev doido, or programs like Crazystack typescript, could turn a long episode into a written reference without recording again.