# 3 steps for Pagar.me Node.js payments > Published 2026-10-26T00:42:06.043Z on https://youblog.app/p/3-steps-for-pagar-me-node-js-payments/ > Source video: https://www.youtube.com/watch?v=l2OASOeXCA4 A 30 BRL monthly charge, one saved card, and one MongoDB document. The 2020 Dev doido lesson builds a Pagar.me Node.js payments flow around those three pieces, and the pattern is still the shape of stored-card billing through the Pagar.me API today. ## How Pagar.me Node.js payments flow from card to database Pagar.me Node.js payments follow four steps: hash the card on the client, post the hash to an Express route, create a transaction through the [Pagar.me API](https://docs.pagar.me/docs/getting-started), then store the transaction result and a saved card in MongoDB. The 2020 Gustavo Dev Doido episode builds exactly that flow. The video was published on 24 May 2020 and is the third part of a series. It is Portuguese-language instruction from a developer known on the channel as Dev doido, and it targets a Brazilian audience creating RG, CPF, address and customer objects, which is why terms like `document` and `country` matter in every request. One detail the transcript makes clear: the backend must never receive a raw card number or CVV. A card hash, generated with the Pagar.me card encryption routine, is what crosses the network. The other detail is storage. Saving the card lets the next charge reuse the card ID and skip data entry, which is what the episode demonstrates at the end with a MongoDB document the speaker calls `card`. ## Why card hashing happens before the request A card hash is a one-way protection step: the client turns card data into a value your server can forward, so the API accepts the charge without the server touching the number. The lesson uses AES encryption to produce that value. The speaker does not encrypt once and send it. The backend decrypts the value, keeps the raw data in memory briefly, and sends it to Pagar.me in the transaction payload, which keeps the sensitive value out of the network request your own server receives. ## Which Pagar.me API versions and libraries apply in 2026 Pagar.me has published newer API generations since 2020, so check the version your account uses before copying any request body from this article. The 2020 lesson calls endpoints under the `/1` path, and that historical state should be labeled as such. The JavaScript client discussed in the series is [pagarme-js](https://github.com/pagarme/pagarme-js), an official Pagar.me library covering the API, card hashing, postback signature validation and document validation. Its maintainers describe it as working in the browser and in Node.js. Two things follow. First, the client library version you install determines which endpoints and payload shapes it wraps. Second, the card hashing routine discussed in the 2020 episode overlapped with a separate encryption helper, which is why the speaker says he could not get a clean client-side path in React. ## What the transaction payload must contain A credit card transaction payload for the Pagar.me API carries an amount, a payment method, either a card hash or a saved card ID, customer data, billing address, and item lines. The lesson includes all of them, and a few fields the speaker says he does not understand. - Amount in BRL cents for the charge - Payment method set to credit card - Card hash on first purchase, saved card ID on repeat - Customer object with name, email, phone, CPF document, and address - Item list with unit price and quantity - Optional metadata the merchant defines Missing fields break the request. The episode shows the speaker forgetting the customer email inside the card object and returning to add it, and the transaction failing before the fix. ## How to save a card for later charges Saving the card means storing the card ID returned by Pagar.me alongside the customer who owns it, so the next transaction references that ID instead of a hash. The lesson models this as a separate `Card` document. - The card document records the customer ID, brand, masked number, and holder name - The mask keeps the first digits, replaces six with asterisks, then keeps the last digits - The deletion handler checks the logged-in user owns the card before removing it That last check matters. The episode names it explicitly: deleting another customer's card would be an invalid operation, so the handler compares the card's user field with the authenticated user. ## Storing the result without duplicate records The transaction document stores the transaction ID from Pagar.me, the status, the authorization code, the risk level, the card ID and the customer ID. The lesson also sets a due date thirty days out using Moment.js and a dedicated update method. Two storage choices in the lesson deserve scrutiny. First, numbers are converted to and from strings to fit MongoDB fields. Second, a `firewall` field is saved into the user document, then removed as redundant. Both are implementation details of that codebase rather than Pagar.me requirements. For repeat charges, the flow reads the saved card ID from your database, then sends it in place of the card hash. That is the whole point of saving the card. ## Error handling and the limits of the original code The lesson wraps transaction creation in a try/catch that distinguishes Pagar.me errors from other failures, returns a 500 status on unexpected errors, and limits input handling to required fields. Field validation is explicitly deferred. The speaker says he will return to validate CPF and other mandatory fields later, which leaves an obvious gap for anyone adapting the code. Pagar.me's own documentation lists which fields are mandatory per endpoint. The network-level error shape is also version-dependent. Checking whether an error response object exists before reading it is safer than assuming a fixed structure, and the exact shape should be read from the current API reference. ## Integrating Pagar.me Node.js payments into a larger stack The same transaction pattern appears in broader e-commerce builds. [CrazyStack](https://crazystack.com.br) teaches payment integration alongside authentication, cart and order flows, and its Crazystack TypeScript stack treats the gateway as one layer in a typed backend rather than a standalone script. That framing is more useful than copying a single controller. A typed backend forces you to declare the transaction response shape, the card document, and the error branches, which is where the 2020 lesson relies on improvisation. If you are working in TypeScript, model the two card branches as separate functions with different input types: one takes a card hash, the other takes a saved card ID. The compiler then prevents mixing them. ## FAQ - **Do I need a Pagar.me API key in the backend?** Yes. The key authenticates your server against the Pagar.me API and should never reach the browser. The 2020 episode passes it to the client library when initializing the connection. - **Can I send raw card numbers to my own server?** No. The lesson's whole design exists to avoid that. The client sends an encrypted string, and the backend decrypts it before forwarding to Pagar.me. - **Why did the React integration fail in the episode?** The speaker says the available library did not offer a working client-side path for his React setup, so he moved the encryption into the backend for the demonstration. - **How long should the due date be?** The lesson uses thirty days from the transaction date. The interval is a business rule, not an API constraint. - **Does saving a card charge the customer again?** No. Saving the card stores a reference so a later transaction can use it without new card data. - **What happens on an unexpected error?** The controller returns status 500. Pagar.me-specific errors are forwarded to the user instead of a generic message. - **Is the 2020 code still current?** The overall flow of hash, charge, save card still applies, but endpoint paths, library versions and payload fields change, so verify against the current Pagar.me reference. - **Which fields are mandatory?** It varies by endpoint and by payment method. The Pagar.me documentation lists them per request. - **Can I delete a saved card?** Yes, and the lesson's deletion handler checks ownership first, since removing another customer's card would be an invalid operation. - **Where should the transaction be stored?** In your own database, keyed to the user. The lesson uses MongoDB, but any store works as long as the card ID and status are saved. ## Turning recorded technical knowledge into a written reference A 36-minute video can explain a payment flow the way a document cannot: you watch the failure, the fix, and the reasoning in sequence. The cost is that the explanation is trapped in one media format, with no line to search and no code to copy cleanly. If you have recorded walkthroughs like this one, [Skala blog](https://skalablog.com) turns a YouTube URL into a transcription and then into an article draft. The video becomes something readers can scan, link to, and return to. [Skala Blog](https://skalablog.com) [Source video](https://www.youtube.com/watch?v=l2OASOeXCA4)