Checkout transparente para WooCommerce: como integrar cartão, Pix e boleto sem tirar o cliente da loja
Um guia estratégico para lojistas e equipes técnicas que querem usar o WooCommerce com uma experiência de pagamento integrada, responsiva e orientada à conversão.
No WooCommerce, a escolha do meio de pagamento não termina na instalação de um plugin. Checkout Blocks, temas, campos brasileiros, antifraude, webhooks e estados do pedido precisam trabalhar juntos para que o cliente veja simplicidade enquanto a operação mantém controle.
O ponto de partida
A IOPAY mantém atualmente uma página e documentação específicas para seu módulo de WooCommerce, com checkout transparente e suporte a cartão, Pix e boleto; isso transforma o tema em uma oportunidade real de aquisição e não apenas em conteúdo de topo de funil. A IOPAY trabalha esse assunto dentro de uma visão mais ampla de infraestrutura de pagamentos: checkout, meios de pagamento, APIs, SDKs, módulos para e-commerce, Link de Pagamento, segurança e gestão operacional precisam conversar entre si. O objetivo deste guia é explicar o tema de forma suficientemente prática para ajudar quem decide, quem implementa e quem opera — sem transformar o artigo em uma peça publicitária ou em uma documentação de endpoint.
O que significa checkout transparente no WooCommerce
Em checkout transparente para woocommerce, o cliente conclui a etapa de pagamento dentro da experiência da própria loja. Isso importa porque reduzir redirecionamentos pode preservar contexto e confiança. É comum analisar esse tema apenas pelo componente visível ao cliente, mas a qualidade da operação depende do que acontece antes, durante e depois da confirmação do pagamento. Uma decisão aparentemente simples pode afetar conversão, risco, conciliação, suporte e capacidade de evolução. Por isso, o desenho deve partir da jornada real: quem inicia a cobrança, quais dados são conhecidos, qual é o canal, como o status será confirmado e o que acontece se houver timeout, recusa, cancelamento ou mudança posterior de estado. Quanto mais explícitas forem essas regras, menor a dependência de exceções manuais e maior a previsibilidade para equipes de produto, tecnologia, atendimento e financeiro.
Uma abordagem prática é integrar o método de pagamento ao fluxo nativo sem esconder estados e mensagens importantes. O resultado precisa ser acompanhado por abandono por etapa e conclusão por dispositivo. Além de olhar o evento de pagamento isoladamente, vale conectar os indicadores à origem da venda, ao perfil do cliente e ao comportamento posterior da transação. Esse cuidado evita otimizações locais que parecem boas no checkout, mas criam custo em chargeback, retrabalho, conciliação ou atendimento. O principal risco é confundir transparência visual com ausência de requisitos de segurança; por isso, a implementação deve prever logs, estados claros, responsáveis por cada exceção e um processo de revisão contínua. Em pagamentos, estabilidade não significa ausência de falhas: significa saber identificar rapidamente o que ocorreu, impedir duplicidades, preservar a experiência do comprador e permitir que a empresa aja com dados.
Plugin, tema e versão do WooCommerce
Quando o assunto é checkout transparente para woocommerce, compatibilidade entre plugin, WordPress, WooCommerce e tema precisa ser tratada como requisito de produção. Isso importa porque mudanças de versão podem alterar checkout e hooks. É comum analisar esse tema apenas pelo componente visível ao cliente, mas a qualidade da operação depende do que acontece antes, durante e depois da confirmação do pagamento. Uma decisão aparentemente simples pode afetar conversão, risco, conciliação, suporte e capacidade de evolução. Por isso, o desenho deve partir da jornada real: quem inicia a cobrança, quais dados são conhecidos, qual é o canal, como o status será confirmado e o que acontece se houver timeout, recusa, cancelamento ou mudança posterior de estado. Quanto mais explícitas forem essas regras, menor a dependência de exceções manuais e maior a previsibilidade para equipes de produto, tecnologia, atendimento e financeiro.
Uma abordagem prática é manter matriz de versões testadas e ambiente de homologação. O resultado precisa ser acompanhado por falhas por versão e tickets após atualização. Além de olhar o evento de pagamento isoladamente, vale conectar os indicadores à origem da venda, ao perfil do cliente e ao comportamento posterior da transação. Esse cuidado evita otimizações locais que parecem boas no checkout, mas criam custo em chargeback, retrabalho, conciliação ou atendimento. O principal risco é atualizar produção sem teste; por isso, a implementação deve prever logs, estados claros, responsáveis por cada exceção e um processo de revisão contínua. Em pagamentos, estabilidade não significa ausência de falhas: significa saber identificar rapidamente o que ocorreu, impedir duplicidades, preservar a experiência do comprador e permitir que a empresa aja com dados.
Checkout clássico e Checkout Blocks
Na prática, WooCommerce possui arquiteturas de checkout que exigem extensibilidade compatível. Isso importa porque métodos antigos podem não se comportar da mesma forma nos blocos. É comum analisar esse tema apenas pelo componente visível ao cliente, mas a qualidade da operação depende do que acontece antes, durante e depois da confirmação do pagamento. Uma decisão aparentemente simples pode afetar conversão, risco, conciliação, suporte e capacidade de evolução. Por isso, o desenho deve partir da jornada real: quem inicia a cobrança, quais dados são conhecidos, qual é o canal, como o status será confirmado e o que acontece se houver timeout, recusa, cancelamento ou mudança posterior de estado. Quanto mais explícitas forem essas regras, menor a dependência de exceções manuais e maior a previsibilidade para equipes de produto, tecnologia, atendimento e financeiro.
Uma abordagem prática é validar suporte ao fluxo usado pela loja e seguir APIs oficiais. O resultado precisa ser acompanhado por conversão e erros por tipo de checkout. Além de olhar o evento de pagamento isoladamente, vale conectar os indicadores à origem da venda, ao perfil do cliente e ao comportamento posterior da transação. Esse cuidado evita otimizações locais que parecem boas no checkout, mas criam custo em chargeback, retrabalho, conciliação ou atendimento. O principal risco é assumir que um gateway clássico funciona automaticamente em Blocks; por isso, a implementação deve prever logs, estados claros, responsáveis por cada exceção e um processo de revisão contínua. Em pagamentos, estabilidade não significa ausência de falhas: significa saber identificar rapidamente o que ocorreu, impedir duplicidades, preservar a experiência do comprador e permitir que a empresa aja com dados.
Cartão de crédito e parcelamento
Do ponto de vista de produto e operação, parcelamento precisa ser apresentado de forma clara e performática. Isso importa porque o excesso de opções ou cálculo incorreto de total cria desistência. É comum analisar esse tema apenas pelo componente visível ao cliente, mas a qualidade da operação depende do que acontece antes, durante e depois da confirmação do pagamento. Uma decisão aparentemente simples pode afetar conversão, risco, conciliação, suporte e capacidade de evolução. Por isso, o desenho deve partir da jornada real: quem inicia a cobrança, quais dados são conhecidos, qual é o canal, como o status será confirmado e o que acontece se houver timeout, recusa, cancelamento ou mudança posterior de estado. Quanto mais explícitas forem essas regras, menor a dependência de exceções manuais e maior a previsibilidade para equipes de produto, tecnologia, atendimento e financeiro.
Uma abordagem prática é exibir parcelas, total e eventuais regras comerciais antes do envio. O resultado precisa ser acompanhado por uso por faixa de parcelas e conversão. Além de olhar o evento de pagamento isoladamente, vale conectar os indicadores à origem da venda, ao perfil do cliente e ao comportamento posterior da transação. Esse cuidado evita otimizações locais que parecem boas no checkout, mas criam custo em chargeback, retrabalho, conciliação ou atendimento. O principal risco é alterar preço sem transparência; por isso, a implementação deve prever logs, estados claros, responsáveis por cada exceção e um processo de revisão contínua. Em pagamentos, estabilidade não significa ausência de falhas: significa saber identificar rapidamente o que ocorreu, impedir duplicidades, preservar a experiência do comprador e permitir que a empresa aja com dados.
Pix no checkout
Para uma empresa que quer escalar, Pix precisa combinar geração rápida e confirmação assíncrona. Isso importa porque o comprador pode pagar fora da aba e voltar depois. É comum analisar esse tema apenas pelo componente visível ao cliente, mas a qualidade da operação depende do que acontece antes, durante e depois da confirmação do pagamento. Uma decisão aparentemente simples pode afetar conversão, risco, conciliação, suporte e capacidade de evolução. Por isso, o desenho deve partir da jornada real: quem inicia a cobrança, quais dados são conhecidos, qual é o canal, como o status será confirmado e o que acontece se houver timeout, recusa, cancelamento ou mudança posterior de estado. Quanto mais explícitas forem essas regras, menor a dependência de exceções manuais e maior a previsibilidade para equipes de produto, tecnologia, atendimento e financeiro.
Uma abordagem prática é mostrar QR Code e copia e cola e atualizar o pedido por evento. O resultado precisa ser acompanhado por tempo até pagamento e abandono após geração. Além de olhar o evento de pagamento isoladamente, vale conectar os indicadores à origem da venda, ao perfil do cliente e ao comportamento posterior da transação. Esse cuidado evita otimizações locais que parecem boas no checkout, mas criam custo em chargeback, retrabalho, conciliação ou atendimento. O principal risco é marcar pedido como pago apenas por exibir o QR; por isso, a implementação deve prever logs, estados claros, responsáveis por cada exceção e um processo de revisão contínua. Em pagamentos, estabilidade não significa ausência de falhas: significa saber identificar rapidamente o que ocorreu, impedir duplicidades, preservar a experiência do comprador e permitir que a empresa aja com dados.
Boleto como opção
Em operações digitais mais maduras, boleto atende jornadas específicas e possui ciclo de compensação distinto. Isso importa porque misturar boleto com pagamento instantâneo cria estados confusos. É comum analisar esse tema apenas pelo componente visível ao cliente, mas a qualidade da operação depende do que acontece antes, durante e depois da confirmação do pagamento. Uma decisão aparentemente simples pode afetar conversão, risco, conciliação, suporte e capacidade de evolução. Por isso, o desenho deve partir da jornada real: quem inicia a cobrança, quais dados são conhecidos, qual é o canal, como o status será confirmado e o que acontece se houver timeout, recusa, cancelamento ou mudança posterior de estado. Quanto mais explícitas forem essas regras, menor a dependência de exceções manuais e maior a previsibilidade para equipes de produto, tecnologia, atendimento e financeiro.
Uma abordagem prática é usar vencimento claro e pedidos pendentes até confirmação. O resultado precisa ser acompanhado por boletos gerados versus pagos. Além de olhar o evento de pagamento isoladamente, vale conectar os indicadores à origem da venda, ao perfil do cliente e ao comportamento posterior da transação. Esse cuidado evita otimizações locais que parecem boas no checkout, mas criam custo em chargeback, retrabalho, conciliação ou atendimento. O principal risco é expedir antes da confirmação; por isso, a implementação deve prever logs, estados claros, responsáveis por cada exceção e um processo de revisão contínua. Em pagamentos, estabilidade não significa ausência de falhas: significa saber identificar rapidamente o que ocorreu, impedir duplicidades, preservar a experiência do comprador e permitir que a empresa aja com dados.
Campos brasileiros e dados do cliente
Em checkout transparente para woocommerce, integrações brasileiras frequentemente dependem de CPF, telefone e endereço consistentes. Isso importa porque dados ausentes quebram antifraude e criação de transação. É comum analisar esse tema apenas pelo componente visível ao cliente, mas a qualidade da operação depende do que acontece antes, durante e depois da confirmação do pagamento. Uma decisão aparentemente simples pode afetar conversão, risco, conciliação, suporte e capacidade de evolução. Por isso, o desenho deve partir da jornada real: quem inicia a cobrança, quais dados são conhecidos, qual é o canal, como o status será confirmado e o que acontece se houver timeout, recusa, cancelamento ou mudança posterior de estado. Quanto mais explícitas forem essas regras, menor a dependência de exceções manuais e maior a previsibilidade para equipes de produto, tecnologia, atendimento e financeiro.
Uma abordagem prática é validar campos antes do pagamento e reduzir redundância. O resultado precisa ser acompanhado por erros de validação e abandono. Além de olhar o evento de pagamento isoladamente, vale conectar os indicadores à origem da venda, ao perfil do cliente e ao comportamento posterior da transação. Esse cuidado evita otimizações locais que parecem boas no checkout, mas criam custo em chargeback, retrabalho, conciliação ou atendimento. O principal risco é pedir dados desnecessários ou validar tarde demais; por isso, a implementação deve prever logs, estados claros, responsáveis por cada exceção e um processo de revisão contínua. Em pagamentos, estabilidade não significa ausência de falhas: significa saber identificar rapidamente o que ocorreu, impedir duplicidades, preservar a experiência do comprador e permitir que a empresa aja com dados.
Antifraude sem destruir conversão
Quando o assunto é checkout transparente para woocommerce, segurança deve usar contexto suficiente sem criar barreiras indiscriminadas. Isso importa porque bloqueio excessivo transforma bons compradores em falsos positivos. É comum analisar esse tema apenas pelo componente visível ao cliente, mas a qualidade da operação depende do que acontece antes, durante e depois da confirmação do pagamento. Uma decisão aparentemente simples pode afetar conversão, risco, conciliação, suporte e capacidade de evolução. Por isso, o desenho deve partir da jornada real: quem inicia a cobrança, quais dados são conhecidos, qual é o canal, como o status será confirmado e o que acontece se houver timeout, recusa, cancelamento ou mudança posterior de estado. Quanto mais explícitas forem essas regras, menor a dependência de exceções manuais e maior a previsibilidade para equipes de produto, tecnologia, atendimento e financeiro.
Uma abordagem prática é enviar dados completos, analisar motivos e revisar regras. O resultado precisa ser acompanhado por aprovação, fraude e falso positivo. Além de olhar o evento de pagamento isoladamente, vale conectar os indicadores à origem da venda, ao perfil do cliente e ao comportamento posterior da transação. Esse cuidado evita otimizações locais que parecem boas no checkout, mas criam custo em chargeback, retrabalho, conciliação ou atendimento. O principal risco é otimizar só a taxa de fraude; por isso, a implementação deve prever logs, estados claros, responsáveis por cada exceção e um processo de revisão contínua. Em pagamentos, estabilidade não significa ausência de falhas: significa saber identificar rapidamente o que ocorreu, impedir duplicidades, preservar a experiência do comprador e permitir que a empresa aja com dados.
Responsividade e mobile
Na prática, grande parte do tráfego de e-commerce chega por dispositivos móveis. Isso importa porque um checkout que funciona no desktop pode falhar em teclado, viewport ou autenticação móvel. É comum analisar esse tema apenas pelo componente visível ao cliente, mas a qualidade da operação depende do que acontece antes, durante e depois da confirmação do pagamento. Uma decisão aparentemente simples pode afetar conversão, risco, conciliação, suporte e capacidade de evolução. Por isso, o desenho deve partir da jornada real: quem inicia a cobrança, quais dados são conhecidos, qual é o canal, como o status será confirmado e o que acontece se houver timeout, recusa, cancelamento ou mudança posterior de estado. Quanto mais explícitas forem essas regras, menor a dependência de exceções manuais e maior a previsibilidade para equipes de produto, tecnologia, atendimento e financeiro.
Uma abordagem prática é testar aparelhos, browsers e métodos de entrada reais. O resultado precisa ser acompanhado por conversão mobile e erros de interface. Além de olhar o evento de pagamento isoladamente, vale conectar os indicadores à origem da venda, ao perfil do cliente e ao comportamento posterior da transação. Esse cuidado evita otimizações locais que parecem boas no checkout, mas criam custo em chargeback, retrabalho, conciliação ou atendimento. O principal risco é homologar apenas em um navegador; por isso, a implementação deve prever logs, estados claros, responsáveis por cada exceção e um processo de revisão contínua. Em pagamentos, estabilidade não significa ausência de falhas: significa saber identificar rapidamente o que ocorreu, impedir duplicidades, preservar a experiência do comprador e permitir que a empresa aja com dados.
Webhooks e atualização do pedido
Do ponto de vista de produto e operação, o estado do pedido não deve depender só da resposta da tela. Isso importa porque pagamentos podem mudar de estado depois da requisição inicial. É comum analisar esse tema apenas pelo componente visível ao cliente, mas a qualidade da operação depende do que acontece antes, durante e depois da confirmação do pagamento. Uma decisão aparentemente simples pode afetar conversão, risco, conciliação, suporte e capacidade de evolução. Por isso, o desenho deve partir da jornada real: quem inicia a cobrança, quais dados são conhecidos, qual é o canal, como o status será confirmado e o que acontece se houver timeout, recusa, cancelamento ou mudança posterior de estado. Quanto mais explícitas forem essas regras, menor a dependência de exceções manuais e maior a previsibilidade para equipes de produto, tecnologia, atendimento e financeiro.
Uma abordagem prática é consumir eventos idempotentes e reconciliar o status. O resultado precisa ser acompanhado por atrasos de atualização e divergências. Além de olhar o evento de pagamento isoladamente, vale conectar os indicadores à origem da venda, ao perfil do cliente e ao comportamento posterior da transação. Esse cuidado evita otimizações locais que parecem boas no checkout, mas criam custo em chargeback, retrabalho, conciliação ou atendimento. O principal risco é duplicar processamento em webhook repetido; por isso, a implementação deve prever logs, estados claros, responsáveis por cada exceção e um processo de revisão contínua. Em pagamentos, estabilidade não significa ausência de falhas: significa saber identificar rapidamente o que ocorreu, impedir duplicidades, preservar a experiência do comprador e permitir que a empresa aja com dados.
Desempenho e Core Web Vitals
Para uma empresa que quer escalar, scripts e chamadas no checkout competem com a intenção de compra. Isso importa porque latência aumenta percepção de risco e abandono. É comum analisar esse tema apenas pelo componente visível ao cliente, mas a qualidade da operação depende do que acontece antes, durante e depois da confirmação do pagamento. Uma decisão aparentemente simples pode afetar conversão, risco, conciliação, suporte e capacidade de evolução. Por isso, o desenho deve partir da jornada real: quem inicia a cobrança, quais dados são conhecidos, qual é o canal, como o status será confirmado e o que acontece se houver timeout, recusa, cancelamento ou mudança posterior de estado. Quanto mais explícitas forem essas regras, menor a dependência de exceções manuais e maior a previsibilidade para equipes de produto, tecnologia, atendimento e financeiro.
Uma abordagem prática é reduzir dependências e medir front-end e backend. O resultado precisa ser acompanhado por tempo até interação e tempo da autorização. Além de olhar o evento de pagamento isoladamente, vale conectar os indicadores à origem da venda, ao perfil do cliente e ao comportamento posterior da transação. Esse cuidado evita otimizações locais que parecem boas no checkout, mas criam custo em chargeback, retrabalho, conciliação ou atendimento. O principal risco é adicionar scripts sem orçamento de performance; por isso, a implementação deve prever logs, estados claros, responsáveis por cada exceção e um processo de revisão contínua. Em pagamentos, estabilidade não significa ausência de falhas: significa saber identificar rapidamente o que ocorreu, impedir duplicidades, preservar a experiência do comprador e permitir que a empresa aja com dados.
Suporte e troubleshooting
Em operações digitais mais maduras, lojas WooCommerce combinam muitos plugins e customizações. Isso importa porque conflitos podem surgir fora do módulo de pagamento. É comum analisar esse tema apenas pelo componente visível ao cliente, mas a qualidade da operação depende do que acontece antes, durante e depois da confirmação do pagamento. Uma decisão aparentemente simples pode afetar conversão, risco, conciliação, suporte e capacidade de evolução. Por isso, o desenho deve partir da jornada real: quem inicia a cobrança, quais dados são conhecidos, qual é o canal, como o status será confirmado e o que acontece se houver timeout, recusa, cancelamento ou mudança posterior de estado. Quanto mais explícitas forem essas regras, menor a dependência de exceções manuais e maior a previsibilidade para equipes de produto, tecnologia, atendimento e financeiro.
Uma abordagem prática é registrar logs úteis e reproduzir falhas em staging. O resultado precisa ser acompanhado por tempo médio de diagnóstico. Além de olhar o evento de pagamento isoladamente, vale conectar os indicadores à origem da venda, ao perfil do cliente e ao comportamento posterior da transação. Esse cuidado evita otimizações locais que parecem boas no checkout, mas criam custo em chargeback, retrabalho, conciliação ou atendimento. O principal risco é debugar diretamente em produção; por isso, a implementação deve prever logs, estados claros, responsáveis por cada exceção e um processo de revisão contínua. Em pagamentos, estabilidade não significa ausência de falhas: significa saber identificar rapidamente o que ocorreu, impedir duplicidades, preservar a experiência do comprador e permitir que a empresa aja com dados.
Quando evoluir de plugin para API
Em checkout transparente para woocommerce, plugin acelera implantação, mas algumas operações precisam de controle adicional. Isso importa porque ERP, marketplace, roteamento ou jornadas próprias podem ultrapassar o escopo padrão. É comum analisar esse tema apenas pelo componente visível ao cliente, mas a qualidade da operação depende do que acontece antes, durante e depois da confirmação do pagamento. Uma decisão aparentemente simples pode afetar conversão, risco, conciliação, suporte e capacidade de evolução. Por isso, o desenho deve partir da jornada real: quem inicia a cobrança, quais dados são conhecidos, qual é o canal, como o status será confirmado e o que acontece se houver timeout, recusa, cancelamento ou mudança posterior de estado. Quanto mais explícitas forem essas regras, menor a dependência de exceções manuais e maior a previsibilidade para equipes de produto, tecnologia, atendimento e financeiro.
Uma abordagem prática é usar plugin onde ele resolve e API quando o negócio exige orquestração. O resultado precisa ser acompanhado por custo de manutenção e tempo de evolução. Além de olhar o evento de pagamento isoladamente, vale conectar os indicadores à origem da venda, ao perfil do cliente e ao comportamento posterior da transação. Esse cuidado evita otimizações locais que parecem boas no checkout, mas criam custo em chargeback, retrabalho, conciliação ou atendimento. O principal risco é customizar tanto o plugin que ele se torne um fork permanente; por isso, a implementação deve prever logs, estados claros, responsáveis por cada exceção e um processo de revisão contínua. Em pagamentos, estabilidade não significa ausência de falhas: significa saber identificar rapidamente o que ocorreu, impedir duplicidades, preservar a experiência do comprador e permitir que a empresa aja com dados.
Checklist de decisão e implementação
- Defina o objetivo de negócio e a jornada que será atendida.
- Mapeie estados de pagamento, erros, cancelamentos, estornos e eventos assíncronos.
- Separe ambiente de testes e produção e documente o processo de homologação.
- Defina indicadores de conversão, risco, disponibilidade e conciliação.
- Garanta rastreabilidade por pedido, cobrança, transação e cliente.
- Planeje suporte, observabilidade e processo de rollback antes do go-live.
- Revise periodicamente a integração e as mudanças da plataforma utilizada.
Perguntas frequentes
A IOPAY tem plugin para WooCommerce?
Sim. O site atual da IOPAY apresenta um módulo específico para WooCommerce com checkout transparente e meios como cartão, Pix e boleto.
Checkout transparente significa que o cliente não sai da loja?
Em termos de experiência, a proposta é concluir a etapa de pagamento integrada à loja. Alguns mecanismos de autenticação podem abrir fluxos controlados quando necessário.
WooCommerce Checkout Blocks mudam a integração?
Podem mudar. A documentação do WooCommerce mantém APIs e pontos de extensibilidade específicos para Cart e Checkout Blocks.
É possível oferecer Pix e boleto no mesmo checkout?
Sim, desde que cada modalidade tenha estados, instruções e confirmação tratados corretamente.
Preciso de ambiente de homologação?
É altamente recomendável para testar versões, tema, plugins, webhooks e cenários de erro antes de publicar mudanças.
Quando usar API em vez de plugin?
Quando a operação precisa de jornadas customizadas, integrações complexas ou controle que ultrapasse o fluxo padrão do WooCommerce.
Conclusão
Um bom checkout WooCommerce esconde complexidade do comprador sem esconder complexidade da equipe que o opera. Em vez de tratar pagamentos como uma etapa isolada do pedido, empresas mais maduras transformam a camada de cobrança em infraestrutura de crescimento: ela precisa converter, resistir a falhas, oferecer segurança, gerar dados confiáveis e se adaptar aos canais em que a venda acontece.
Como a IOPAY entra nessa estratégia
A página atual da IOPAY para WooCommerce descreve módulo gratuito, checkout transparente, cartão, Pix, boleto, parcelamento, antifraude e integração com a plataforma; esses recursos devem ser confirmados na documentação vigente antes da publicação. A proposta editorial aqui é simples: primeiro explicar o problema e os trade-offs; depois mostrar onde uma infraestrutura de pagamentos bem integrada pode reduzir atrito e acelerar a operação. Antes da publicação, recomenda-se validar no site e na documentação técnica da IOPAY versões, disponibilidade de recursos e condições comerciais que possam ter sido atualizadas.