# Mercado Pago transparent checkout | Upmy portfolio URL: https://upmy.com.br/en/work/mercado-pago-transparent-checkout/ Language: en Payments and reconciliation · E-commerce ## Mercado Pago transparent checkout Pix, cards and boleto connected to checkout, with confirmation against order identity, currency and amount. [Request a quote↗](https://wa.me/5516988724774?text=Hi%20Weliton!%20I'd%20like%20a%20quote%20for%20Mercado%20Pago%20transparent%20checkout.)[Explore the workflow ↗](#workflow) Implemented · test deployment documented 5 workflow stages Custom development UPMY / INTEGRATION ↗ 01 Store checkout → 02 Mercado Pago payment → 03 Order reconciliation WORKFLOW MAP Need something similar? [Request a quote ↗](https://wa.me/5516988724774?text=Hi%20Weliton!%20I'd%20like%20a%20quote%20for%20Mercado%20Pago%20transparent%20checkout.) 01 / Context ### The challenge The store needed payment options and consistent order updates without repeated notifications rerunning operations that had already completed. A checkout needs to keep the customer's experience aligned with the financial state of the order. A card can be declined, a Pix charge can be paid later, and a notification can arrive more than once. This project addressed both the payment interface and the rules connecting those responses to store operations. The move to the UP architecture started from an existing project integration. Version 3.0.0 uses Brazilian customer data captured with the order, requires webhook signatures and reduces repeated technical logging. It retains transparent Pix, card and boleto flows, with Checkout Pro as a distinct hosted option. 02 / Step by step ### How the workflow works - 01 #### Choose a payment method The customer selects an option enabled by the store. Each method has its own preparation while preserving the total and the identities of the related orders. - 02 #### Prepare payment For cards, official Mercado Pago fields generate a token. For Pix and boleto, the server prepares the charge with the expiration and information required by the method. - 03 #### Request the transaction The request includes checkout references and idempotency mechanisms. The response can represent an approved, pending or declined payment. - 04 #### Verify the response Webhooks require a signature, and reconciliation compares currency, amount, payment method and associated orders before changing the local record. - 05 #### Update without repeating Later state changes update the existing payment. The adaptation avoids repeating initial inventory, messaging and history operations simply because another notification arrives. 03 / Implementation ### The work The UP version organizes payment methods, uses official card fields and verifies payment identity before changing local status. - Transparent Pix, card and boleto flows - Checkout Pro as a separate option - Reconciliation and deduplicated technical logs #### Card experience with provider-controlled processing Card number, expiration and security-code fields are mounted through the official card integration. The server receives the token required for payment. Installment options are requested after the card is identified, within the store's configuration. The interface also received work on messages and payment states. This makes the flow understandable without promising approval: transaction processing and acceptance remain subject to the provider and the account's conditions. #### Evolution without additional custom tables The UP version uses native payment records and the Brazilian order-data snapshot. Diagnostic logging was centralized and deduplicated, including handling for routine queries and repeated notifications, reducing unnecessary records of successful technical activity. The history documents checks for signatures, transitions, Pix discounts, customer data and syntax, plus a test deployment. An integrated SQLite suite remained pending because of an environment limitation. Each payment method still requires validation before a commercial delivery. 04 / Delivery ### Delivery and context Version 3.0.0 was implemented and deployed to a test server with its own checks passing. The gateway awaited configuration for financial validation. #### Deployment considerations - A test-server deployment is not financial validation of every payment method. - Card approval and installment conditions depend on the provider and account. ### Frequently asked questions Can customers pay without leaving the store? The transparent methods were implemented for that experience. Checkout Pro is a separate hosted option that sends the customer to Mercado Pago. Can this work with my existing checkout? It can be assessed as a quoted project. Scope depends on the Botble version, installed modules and tests needed to preserve order and payment behavior. ### A similar workflow in your business? Tell me which platform you use, how your workflow operates today and what needs to change. Together, we can define the scope, integrations and acceptance checks for your project. [Request a quote↗](https://wa.me/5516988724774?text=Hi%20Weliton!%20I'd%20like%20a%20quote%20for%20Mercado%20Pago%20transparent%20checkout.)Scope and pricing tailored to your project. ### Related services [Botble CMS development and custom pluginsPlugins, integrations and improvements for Botble stores and applications.↗](https://upmy.com.br/en/services/botble-development/)[Payment gateway and API integrationsConnect checkout, billing and payment events to your business systems.↗](https://upmy.com.br/en/services/payment-integration/)[Back to projects ↗](https://upmy.com.br/en/work/)