Before adding Pix, confirm three things: whether your business is eligible with the chosen payment provider, what evidence marks an order as paid, and who handles payment exceptions. Generating a QR code establishes a payment entry point. It does not demonstrate that the store can handle delayed notifications, expired orders, duplicate payments, refunds or reconciliation.
This guide is for businesses operating in Brazil or selling goods to Brazilian customers that are buying or adapting ecommerce software. It covers ordinary one-time purchases. Recurring billing, cross-border settlement and marketplace split payments should have their own agreed scope.
Confirm the merchant entity and provider requirements
Give prospective providers your business registration country, product category, receiving account and target customers before specifying the integration. Buying a plugin first can leave you with software that your account cannot use.
For example, Stripe's Pix documentation identifies supported account locations, business restrictions and BRL presentment. Some businesses outside Brazil can accept Pix from Brazilian customers, but this does not establish eligibility for every foreign entity or describe other providers' requirements.
Ask for written answers to these questions:
Which entity signs the agreement and receives payments? What verification applies to a local company versus an overseas entity?
Is the actual account eligible for the product category and expected transaction amounts? Is separate activation or approval needed?
What are the buyer's payment currency, merchant settlement currency, funds-availability timing and bank-payout arrangements?
Which payment, refund, withdrawal and currency-conversion charges apply, and which agreement or quotation governs them?
Does the current store or plugin version support this provider's interface, and who maintains the integration after upgrades?
Compare quotations using the same order amount and assumed refund rate. Separate payment processing, settlement, conversion and software maintenance costs. A single generic “Pix rate” is not a useful budget without applicable provider terms.
Separate payment confirmation from permission to ship
The store should retain its own order reference, the provider payment ID, amount, currency and payment status. A trusted server-side result, matched to the correct order, should establish payment. Inventory, address and risk checks can then determine whether fulfillment may proceed. A buyer's screenshot, phone confirmation or return to the store should not independently release goods.
A webhook is a status notification sent by the payment provider to the store. Stripe's webhook documentation, for example, explains that events can arrive more than once and out of order. Test that repeated notifications cannot create repeated shipments and that an older event cannot move a paid order back to payment pending. Verify notification authenticity using the provider's prescribed method.
Payment confirmation, fulfillment and refunds are separate steps. This conceptual acceptance flow must be mapped to the chosen provider and store's actual states.
A normal flow is: create an unpaid order, display payment instructions, receive and verify the result, mark it paid, then fulfill after operational checks. When a notification has not arrived, retain a pending-verification state with a lookup and escalation route.
Align payment expiry with inventory reservations
Ask the software vendor to explain two deadlines: when the payment instruction expires and when the store cancels the order and releases reserved inventory. Different systems may control these times. A countdown on the checkout page does not prove they are aligned.
Demonstrate a payment made near the deadline whose confirmation reaches the store after the order closes. The proposed workflow should retrieve and check the payment result. If money was received, staff need an exception record and a decision based on stock availability: restore fulfillment or arrange a refund. The application should neither discard the payment nor revive an order without operational checks.
If a buyer creates another order or generates new payment instructions, retain the relationship between each payment attempt and its order. A notification for an earlier attempt must remain traceable. An “I have paid” button can start verification; it should not directly mark payment successful.
Also walk through checkout on a phone. Check Portuguese instructions, copying payment details, switching to the banking app and returning to a verified order status. A desktop QR-code demonstration alone is insufficient.
Keep refunds and settlement traceable
Distinguish the buyer's payment, provider confirmation and settlement into the merchant's bank account. A real-time payment experience does not establish immediate withdrawal under every acceptance arrangement.
Refunds also need separate requested, processing, successful and failed states. Stripe's Pix guide supports full and partial refunds and notes that a successful request does not itself prove that the customer's account was credited. Verify the applicable window and conditions with the chosen provider instead of treating one provider's rules as universal Pix terms. Refund capabilities and status
As acceptance criteria, require each refund to link to its original payment and retain the requester, reason, amount and outcome. Cumulative refunds must not exceed the amount still refundable. Finance should reconcile payments, refunds, fees and actual settlement using the order and payment references, with discrepancies assigned to an owner. Marketplace operators also need to assess how refunds interact with seller allocations.
Run six acceptance scenarios
The amounts below are demonstration data. Start in the provider's supported test environment; the business must approve any production verification and its amount.
A normal R$120 payment: The amount, currency and order match. One payment produces one fulfillment task.
The same successful event arrives twice: Necessary evidence is retained, without another shipment or another sale being recorded.
The buyer paid but the notification is delayed: Support can investigate and confirm the payment without asking the buyer to pay again to fix the order.
Payment is confirmed after the order closes: An actionable exception appears. Staff check stock, choose fulfillment or refund, and record the decision and owner.
Two successful payments relate to one order: Both provider IDs remain visible. Fulfillment happens once and the excess payment enters refund handling rather than being overwritten or silently allocated to another order.
A R$30 partial refund is requested: Staff can reconcile the payment, refund and remaining amount. A failure or unresolved result is not shown as refunded, and repeated clicks cannot create repeated refunds.
Record each outcome as available, configuration required, development required or unsupported. Attach demonstration evidence, an owner and a delivery date. These are proposed procurement tests, not claims that HUACODE or an individual payment provider already implements every capability.
Confirm eligibility before accepting a development quote
Provide the software vendor with the merchant entity, the provider's eligibility confirmation, operating model, order workflow and test scenarios. Separate the payment interface, notifications and verification, refund administration, reconciliation, launch testing and ongoing maintenance in the quotation. Otherwise, exception handling may become an unexpected post-launch cost.
To discuss Brazilian ecommerce and Pix requirements with HUACODE, bring a sanitized workflow and confirmed provider conditions. Establish who receives the money, when an order can ship and who owns exceptions before selecting the store or development approach.
Sources checked on 2 November 2026. Confirm availability against the actual account and current agreement. Amounts and diagrams are examples for procurement acceptance.