Stops the classic checkout from losing letters typed right after the CEP on some plain-permalink stores, and labels a CNPJ required for companies as required.<\/p>","1.0.4":"
Fixes a wrong house number on some shipping addresses (classic checkout), missing document fields on the block checkout of WooCommerce 8.9 to 9.8, and an unenforced required CNPJ; adds personal-data export and erasure.<\/p>","1.0.3":"
Renamed plugin and internal code prefix ahead of the WordPress.org listing; no change to features.<\/p>","1.0.1":"
Fixes CNPJ input and autofill on the block checkout, and adds individual\/company choice and shipping number\/neighbourhood there.<\/p>","1.0.0":"
Initial release.<\/p>"},"ratings":[],"assets_icons":[],"assets_banners":[],"assets_blueprints":{},"all_blocks":[],"tagged_versions":["1.0.5"],"block_files":[],"assets_screenshots":{"screenshot-1.png":{"filename":"screenshot-1.png","revision":3742035,"resolution":"1","location":"assets","locale":"","width":1280,"height":1152},"screenshot-2.png":{"filename":"screenshot-2.png","revision":3742035,"resolution":"2","location":"assets","locale":"","width":1280,"height":1019},"screenshot-3.png":{"filename":"screenshot-3.png","revision":3742035,"resolution":"3","location":"assets","locale":"","width":1120,"height":828}},"screenshots":{"1":"Checkout fields with input masks, CPF validation and the address filled in from the CEP.","2":"Settings: each field can be disabled, optional or required.","3":"Diagnostics panel \u2014 versions, checkout type, HPOS, and whether the lookups are responding."}},"plugin_section":[],"plugin_tags":[8286,8287,157502,152487,66145],"plugin_category":[45],"plugin_contributors":[283274],"plugin_business_model":[],"class_list":["post-377752","plugin","type-plugin","status-publish","hentry","plugin_tags-brasil","plugin_tags-brazil","plugin_tags-cep","plugin_tags-cnpj","plugin_tags-cpf","plugin_category-ecommerce","plugin_contributors-rebelstudios","plugin_committers-rebelstudios"],"banners":[],"icons":{"svg":false,"icon":"https:\/\/s.w.org\/plugins\/geopattern-icon\/rebel-studios-brazilian-checkout-fields.svg","icon_2x":false,"generated":true},"screenshots":[{"src":"https:\/\/ps.w.org\/rebel-studios-brazilian-checkout-fields\/assets\/screenshot-1.png?rev=3742035","caption":"Checkout fields with input masks, CPF validation and the address filled in from the CEP."},{"src":"https:\/\/ps.w.org\/rebel-studios-brazilian-checkout-fields\/assets\/screenshot-2.png?rev=3742035","caption":"Settings: each field can be disabled, optional or required."},{"src":"https:\/\/ps.w.org\/rebel-studios-brazilian-checkout-fields\/assets\/screenshot-3.png?rev=3742035","caption":"Diagnostics panel \u2014 versions, checkout type, HPOS, and whether the lookups are responding."}],"raw_content":"\n
Rebel Studios Brazilian Checkout Fields<\/strong> adds the fields a Brazilian store needs to the WooCommerce checkout \u2014 CPF, CNPJ, company legal name (Raz\u00e3o Social), RG, state registration (Inscri\u00e7\u00e3o Estadual), street number and neighbourhood (bairro) \u2014 and does three things that are usually missing:<\/p>\n\n The plugin's interface is in Brazilian Portuguese. It is fully internationalized (i18n), so it can be translated into any language through translate.wordpress.org once published.<\/p>\n\n Each field has three states: Disabled<\/strong>, Optional<\/strong> or Required<\/strong>. A store that sells digital products does not need to ask for a CPF; one that invoices companies needs a CNPJ and legal name and nothing else. You decide, without touching code.<\/p>\n\n Compatible with the WooCommerce classic checkout<\/strong> and the block checkout<\/strong>, and with HPOS<\/strong> (High-Performance Order Storage). Data is stored the same way by both checkouts, so an invoicing integration only has to read one format.<\/p>\n\n On the block checkout, customers choose between individual (Pessoa F\u00edsica) and company (Pessoa Jur\u00eddica), and see only the documents for that choice.<\/p>\n\n CEP and CNPJ lookups are made from your server<\/strong>, not from the customer's browser, and are cached. If a lookup service is down, the customer simply types the address \u2014 a purchase is never blocked<\/strong> by a third-party API.<\/p>\n\n To fill an address from a postcode and a company from its registration number, this plugin sends the value the customer typed to two free, public Brazilian services. Every request is made from your server<\/strong> (never the customer's browser), only<\/strong> when a customer enters a CEP or a CNPJ, and the response is cached on your site so the same value is not looked up twice. No data is ever sent to the makers of this plugin.<\/p>\n\n ViaCEP<\/strong> (https:\/\/viacep.com.br\/)\nUsed to turn a Brazilian postcode into a street address. When a customer types an 8-digit CEP, that CEP \u2014 and nothing else \u2014 is sent to ViaCEP, which returns the street, neighbourhood, city and state. No personal data (name, email, document number) is sent. ViaCEP is a free public service that does not publish a separate terms-of-service or privacy-policy page; its usage information is on its website: https:\/\/viacep.com.br\/.<\/p>\n\n BrasilAPI<\/strong> (https:\/\/brasilapi.com.br\/)\nUsed to turn a company registration number into the company's public details. When a customer types a 14-digit CNPJ (a public company registration number, not personal data), that CNPJ \u2014 and nothing else \u2014 is sent to BrasilAPI, which returns the company's public registration data (legal name and registered address). BrasilAPI is a free, open-source community project. Its terms of use are published on its site: https:\/\/brasilapi.com.br\/#termos-de-uso . It does not publish a separate privacy-policy page; the project and its source are documented at https:\/\/brasilapi.com.br\/ .<\/p>\n\n The Diagnostics panel on the settings screen also sends one sample request to each service (at most once every 5 minutes) to show whether it is responding. It uses a fixed example CEP and CNPJ, never customer data.<\/p>\n\n\n It is almost always the checkout type. If your store uses the block checkout<\/strong> and your previous plugin only supported the classic checkout, no fields appear \u2014 which is exactly why this plugin exists.<\/p>\n\n Go to WooCommerce \u2192 Checkout Brasil<\/strong> and look at the Diagnostics<\/strong> panel at the bottom of the page. It tells you which checkout your store uses, whether the fields are active, and whether another plugin is competing for the same fields. Copy that report before opening a support request.<\/p><\/dd>\n Yes. Every field has three states \u2014 Disabled, Optional, Required \u2014 under WooCommerce \u2192 Checkout Brasil<\/strong>. Nothing is forced, including the CPF.<\/p><\/dd>\n You have two checkout-field plugins active at the same time. The Diagnostics panel detects the common ones (Brazilian Market on WooCommerce, Checkout Field Editor, Flexible Checkout Fields). Deactivate one of them.<\/p><\/dd>\n Old orders stay intact \u2014 this plugin deletes nothing. It stores data in its own meta keys ( Yes. A failed lookup is ignored and the customer types the address normally. A purchase is never blocked<\/strong> by a third-party API. The Diagnostics panel shows whether ViaCEP and BrasilAPI are responding right now.<\/p><\/dd>\n They are stored on the order ( Yes, compatibility is declared. Data is saved through the WooCommerce order API, so it works the same with HPOS on or off.<\/p><\/dd>\n The fields use their own names ( Yes, with the official check digits, in the browser and again on the server<\/strong>. An invalid document never reaches the order. Repeated sequences (111.111.111-11) are rejected.<\/p><\/dd>\n No. Lookups go from your server straight to ViaCEP and BrasilAPI, and responses are cached on your site. There is no server of ours in between.<\/p><\/dd>\n\n<\/dl>\n\n\n\n
Every field is optional<\/h4>\n\n
Works with both checkouts<\/h4>\n\n
Privacy and reliability<\/h4>\n\n
External services<\/h3>\n\n
\n
\n
The fields do not appear on my checkout.<\/h3><\/dt>\n
Can I turn off the CPF?<\/h3><\/dt>\n
The fields appear twice.<\/h3><\/dt>\n
I am migrating from \"Brazilian Market on WooCommerce\". Is my old data lost?<\/h3><\/dt>\n
_billing_rsbcf_cpf<\/code>), different from the old plugin's (_billing_cpf<\/code>), precisely to avoid conflicts. New orders use the new keys; old orders remain readable by the old plugin while it is installed.<\/p><\/dd>\nCEP lookup stopped working. Can my customers still buy?<\/h3><\/dt>\n
Do CPF\/CNPJ show up on the invoice?<\/h3><\/dt>\n
_billing_rsbcf_cpf<\/code>, _billing_rsbcf_cnpj<\/code>, _billing_rsbcf_company_legal_name<\/code>) and shown on the order screen, in emails and in the REST API \u2014 which is where NF-e integrations read them. If your integration expects different field names, the rsbcf_order_values<\/code> filter lets you remap them.<\/p><\/dd>\nDoes it work with HPOS?<\/h3><\/dt>\n
Does it work with PagSeguro \/ Mercado Pago \/ PagBank?<\/h3><\/dt>\n
billing_rsbcf_*<\/code>) instead of the generic names several plugins fight over, which is the most common cause of gateway conflicts. If you still hit a conflict, send the Diagnostics report and we can answer on the first reply.<\/p><\/dd>\nIs the CPF really validated?<\/h3><\/dt>\n
Do you receive my customers' data?<\/h3><\/dt>\n
1.0.5<\/h4>\n\n
\n
1.0.4<\/h4>\n\n
\n
1.0.3<\/h4>\n\n
\n
1.0.2<\/h4>\n\n
\n
1.0.1<\/h4>\n\n
\n
1.0.0<\/h4>\n\n
\n