MevvPos — Documentação Mevvsoft

Instalação

O MevvPos exige WordPress 6.0+ e PHP 8.1+. O WooCommerce é opcional. Com o WooCommerce 9.0 ou mais recente ativo, o MevvPos se registra como um método de pagamento no checkout; sem ele, o motor de pagamento ainda carrega e pode ser operado por outro plugin. Versões anteriores declaravam o WooCommerce como uma dependência obrigatória e o WordPress recusava a ativação sem ele — essa exigência acabou.

As duas superfícies de finalização do WooCommerce estão cobertas. O MevvPos regista-se tanto na finalização clássica por shortcode como no mais recente bloco de Finalização. Até à 4.7.1 apenas a página clássica estava ligada, pelo que uma loja que passasse à finalização por blocos perdia por completo a opção de cartão — sem erro, sem aviso, apenas um método de pagamento em falta. Não é preciso configurar mais nada: na página de blocos os campos do cartão, a tabela de prestações e o acréscimo por prestações aparecem da mesma forma.

Envie o plugin em Plugins → Adicionar novo → Enviar plugin e ative-o.
Abra o MevvPos no menu lateral do admin. Também há um atalho dentro do WooCommerce, onde os lojistas costumam procurar as configurações de pagamento.
Na aba Geral, ligue a forma de pagamento e defina o título que o cliente verá na finalização da compra.
Em Bank API, escolha seu provedor — um POS virtual de banco turco ou um dos provedores internacionais — e digite as credenciais que ele forneceu.
Se você escolheu um provedor internacional, copie o endereço de Webhook exibido nessa mesma aba para o painel do próprio provedor. Nada se completa sem ele.
Em Parcelamento e comissão, informe as suas taxas de parcelamento.
Teste com as credenciais de teste do seu banco antes de entrar no ar.

The free plugin creates no database tables and registers no scheduled job. Everything lives in WordPress options and in order meta.

O Pro é um plugin separado, instalado ao lado do gratuito — não é um substituto dele. O plugin gratuito é publicado no WordPress.org, onde tudo o que é publicado pode ser redistribuído sob a GPL; manter o código pago no mesmo pacote o tornaria legalmente redistribuível por qualquer pessoa que apagasse as verificações de licença. A chave de licença é informada na aba Licença.

Abrir WooCommerce → Configurações → Pagamentos → MevvPos redireciona você para a tela do MevvPos. Isso é deliberado: há um único lugar para essas configurações, não dois que possam se contradizer.

Como funciona

O MevvPos fala dois tipos de protocolo de pagamento, e qual deles você recebe decorre do provedor escolhido. Os dois passam pelo mesmo motor e produzem o mesmo registro de pedido.

Formulário assinado — Türkiye: As sete famílias de POS virtual turcas. O MevvPos monta os campos de pagamento, assina-os com sua chave de loja e os envia (POST) ao banco. O cliente se autentica com o 3-D Secure e o banco retorna ao seu site; a assinatura nesse retorno é o que completa o pedido.
Página hospedada e webhook — internacional: Stripe, PayPal, Mollie, Square, Authorize.Net, Checkout.com, Razorpay e Paystack. O MevvPos cria o pagamento no fornecedor através da sua API REST e envia o cliente para a página do próprio fornecedor. A encomenda é concluída por uma resposta do fornecedor: a notificação assinada que chega ao seu endereço de webhook ou — se o cliente regressar antes de ela chegar — uma consulta de estado de servidor para servidor feita a partir da página de retorno. O que nunca conclui uma encomenda por si só é o regresso do navegador.

No lado da Türkiye, o motor faz algo de que os provedores internacionais nunca precisam: decide qual das suas contas recebe o cartão.

Você define um ou mais registros de POS. Um registro de POS é o POS virtual de um banco: suas credenciais, o endereço do gateway, suas taxas de parcelamento.
No checkout, o cliente digita o cartão. Os seis primeiros dígitos — o BIN — identificam o banco que o emitiu.
O MevvPos consulta o BIN e envia o pagamento ao seu POS naquele banco, se você tiver um. Caso contrário, ele recai no seu POS padrão.
O parcelamento só é oferecido quando o cartão pertence ao próprio banco daquele POS, porque bancos não concedem parcelamento em cartões de outro banco.
O cliente passa pelo 3-D Secure no banco, e o banco retorna a um único endereço de callback no seu site.
A assinatura do retorno é verificada com a chave do POS que o pedido realmente usou, o pedido é concluído e o resultado é registrado.

O número do cartão, a validade e o CVV nunca são gravados no seu banco de dados nem na sessão do WooCommerce. Os únicos dados de cartão guardados são os seis primeiros dígitos e o nome do banco reconhecido.

Com os provedores internacionais, nenhum dado de cartão chega ao seu site: o cartão é digitado na própria página do provedor. É isso que os torna o caminho mais curto para um escopo PCI pequeno — e também o motivo pelo qual não têm roteamento por BIN nem parcelamento.

Os provedores internacionais

Os fornecedores internacionais cobrem o mundo fora da Türkiye. Todos usam a página alojada ou redirecionada do próprio fornecedor, por isso os dados do cartão nunca são escritos no seu site. A autenticação também decorre lá, mas o resultado não fica lá: o MevvPos regista se o pagador foi autenticado, envia-o para o banco quando o emissor pede uma verificação adicional e lê o ECI para registar se a responsabilidade por chargeback foi transferida. Quando um fornecedor não comunica o resultado, este é registado como desconhecido e não como seu. Para além do cartão, os métodos locais seguem no campo próprio de cada fornecedor: iDEAL, Bancontact, débito direto SEPA, Klarna, EPS, Przelewy24, BLIK, TWINT, Multibanco e carteiras. É você que escolhe quais um conta oferece, e um método que não escolheu nunca é enviado. Um método cuja moeda não corresponde à encomenda é descartado de imediato — oferecer iDEAL numa encomenda em dólares só faria o pagamento falhar no fornecedor.

Stripe: Uma Checkout Session em mode=payment, que cria um Payment Intent por trás da própria página do Stripe. A chave secreta vai no campo de chave do comerciante e o Webhook signing secret no campo extra. O pedido é completado por um payment_intent.succeeded assinado. O Elements deliberadamente não é usado: usá-lo moveria os campos de cartão para a sua página e ampliaria seu escopo PCI.
PayPal: Orders v2, em três etapas: criar o pedido, o cliente aprová-lo no PayPal e o MevvPos capturá-lo. A terceira etapa é a mais fácil de esquecer — um pedido aprovado que nunca é capturado deixa o dinheiro não recolhido enquanto o pedido parece pago. O ID de cliente REST vai no número do comerciante, o segredo do cliente na chave do comerciante e o Webhook ID no campo extra.
Mollie: Payments API v2. A chave de API — live_… ou test_… — vai no campo de chave do comerciante e não há campo extra, porque a Mollie não assina suas notificações. Veja a seção de webhook abaixo para o que o MevvPos faz em vez disso.
Square: Um Payment Link por meio da Checkout API. Insira o token de acesso como chave do comerciante, além do Location ID e da Webhook signature key. O Square vincula toda venda a uma localização: sem o Location ID nenhum pagamento pode ser criado, e o próprio erro do Square não diz isso com clareza.
Authorize.Net: Accept Hosted. O API Login ID vai no número do comerciante, a Transaction Key na chave do comerciante, e a Signature key no campo extra — um valor diferente da Transaction Key e fácil de confundir com ela. Este é o único provedor que não devolve um endereço de redirecionamento: ele retorna um token que o MevvPos envia (POST) à página hospedada como um formulário.
Checkout.com: A Hosted Payments Page. A chave secreta (sk_…) vai na chave do comerciante e a chave de assinatura do webhook no campo extra; a notificação é assinada com HMAC-SHA256 sobre o corpo em bruto. Um comportamento a prever: o reembolso é aceite de forma assíncrona. A Checkout.com responde à chamada de reembolso com 202 e um id de ação, o que significa que o pedido foi aceite — não que o dinheiro já tenha voltado.
Razorpay: Um Payment Link, para lojas que vendem para a Índia, onde o cartão por si só não chega e o UPI, a banca online e as carteiras são reunidos na página do fornecedor. A Key ID vai no número do comerciante, a Key Secret na chave do comerciante e o segredo do webhook — um valor distinto da Key Secret — no campo extra. A Razorpay devolve dois identificadores que não são intermutáveis: o id da ligação (plink_…) é aquele com que se pergunta o estado, ao passo que um reembolso só é possível com o id do pagamento (pay_…) que a ligação reporta depois de paga.
Paystack: Uma página de transação alojada, para lojas que vendem para a Nigéria, o Gana, a África do Sul, o Quénia e a Costa do Marfim, onde o USSD, a transferência bancária e o dinheiro móvel contam tanto como o cartão. A chave secreta (sk_live_… ou sk_test_…) vai na chave do comerciante e não há campo extra — a notificação é assinada com HMAC-SHA512 usando esse mesmo segredo. Tudo assenta numa única referência: iniciar o pagamento, perguntar o seu estado e reembolsá-lo usam-na toda.

O modo de teste troca para o próprio endereço de sandbox do provedor no PayPal, Square e Authorize.Net. O Stripe e a Mollie separam produção de teste pela chave, não pelo endereço, então ali é a chave que você cola que decide.

Os valores são carregados como números inteiros na unidade menor da moeda de ponta a ponta — kuruş, centavos — e nunca como fração decimal. A Mollie é o único provedor que quer de volta uma string decimal, e quer exatamente o número certo de dígitos para a moeda: 10.0 é recusado onde 10.00 é aceito. Essa string é construída a partir do inteiro, não de um float.

Nenhum dos oito foi verificado de ponta a ponta com uma conta de comerciante real. Cada ficheiro de fornecedor di-lo no seu próprio cabeçalho e enumera as páginas de documentação a partir das quais foi escrito. Os fluxos seguem a documentação publicada dos fornecedores, e os algoritmos de assinatura e os nomes dos campos estão fixados a ela; mas isso não é o mesmo que um pagamento real concluído e não o descreveremos como se fosse. Leia-os como prontos a ligar e a testar contra a sua própria sandbox, não como comprovados em produção.

Registros de POS

A barra de POS fica acima das abas e aparece em todas elas. Cada cartão mostra o banco, o número do estabelecimento e um selo quando algo exige sua atenção.

Padrão: O POS que recebe o pagamento quando nenhuma correspondência melhor é encontrada. Sempre existe exatamente um.
Inativo: Mantido, mas sem cobrar. Use isso em vez de apagar quando um POS está configurado mas ainda não está ativo no banco — do contrário, um cliente com o cartão daquele banco ficaria sem conseguir pagar.
Aguardando uma licença: O registro existe, mas está dormente porque a licença não está ativa. Nada foi apagado; ele retoma de onde parou quando a licença é renovada.
Os dados da API não foram informados: O registro ainda não tem número de estabelecimento.

Os bancos aparecem por uma faixa de cor em vez de um logotipo. Logotipos de banco são marcas registradas, e quinze deles são ao mesmo tempo exposição jurídica e manutenção permanente — você já sabe qual é o seu banco.

O último POS não pode ser excluído e o último habilitado não pode ser desligado. Para parar de aceitar pagamentos com cartão por completo, desligue a forma de pagamento na aba Geral.

There is no cap on the number of provider accounts, and routing between them — by the card’s issuing bank and by the order’s currency — is part of the free plugin. Earlier releases allowed one account; that limit was removed in 4.9.0.

Quando uma licença expira, a conta que continua recebendo não é escolhida ao acaso: é a marcada como padrão, ou então a primeira conta habilitada configurada. Escolher ao acaso significaria que uma loja começaria silenciosamente a receber por um banco diferente numa manhã qualquer.

API do banco — credenciais e o endereço do gateway

Provedor: A lista vem em dois grupos: Türkiye — POS virtual bancário e Provedores de pagamento internacionais. Tudo mais que o formulário pede decorre dessa única escolha, e configurações que não se aplicam à sua escolha nem sequer são exibidas.
Banco: Escolha o banco em que seu POS está. Tanto o endereço do gateway quanto a lista de BINs usada para o parcelamento seguem essa escolha. Instituições ainda sem implementação aparecem com “— yakında” (em breve) e não podem ser selecionadas.
Número do estabelecimento (Client ID): O número de estabelecimento que o banco lhe deu.
Chave do estabelecimento (Store key): A chave de segurança do estabelecimento. Guardada como campo de senha; depois de salva, é exibida mascarada.
Gate URL: O endereço para o qual o formulário de pagamento envia os dados.
Enviar a própria moeda do pedido ao banco: Apenas para o POS virtual turco, e desativado por padrão: o MevvPos envia lira turca, que é o que seu banco espera a menos que você tenha um acordo multimoeda. A moeda faz parte da assinatura, então um valor que seu banco não aceita é recusado sem explicação. Os provedores internacionais recebem a moeda do pedido como ela é e nunca recebem essa pergunta.
Ativar o modo de teste: Interrompe o redirecionamento automático para você inspecionar a requisição antes de ela ser enviada.

Deixar a Store Key em branco ao salvar significa “não altere”. Gravar o valor em branco apagaria a chave e sua loja pararia de aceitar pagamentos sem uma única mensagem de erro. A mesma regra vale para os outros campos secretos.

Algumas famílias precisam de credenciais extras, e o formulário as exibe apenas para o provedor que você escolheu:

Garanti BBVA — Merchant ID, usuário de autorização, senha de autorização.
VakıfBank — Terminal No, e um endereço MPI (deixe vazio para usar o endereço de teste).
PayTR — Merchant Salt.
iyzico, Craftgate, Sipay — sem campos extras: a chave da API vai no Número do estabelecimento e o segredo na Chave do estabelecimento.
Stripe — Webhook signing secret.
PayPal — Webhook ID.
Square — Location ID e Webhook signature key.
Authorize.Net — Signature key, usada apenas para webhooks.
Mollie — nenhum campo extra: a chave de API vai em Merchant key.

Essas credenciais extras entram na assinatura. Se uma faltar, a assinatura é calculada com um valor vazio e o banco recusa o pagamento em silêncio — sem erro, sem mensagem, apenas uma recusa.

Para os sete bancos NestPay, o endereço do gateway é preenchido a partir da sua escolha de banco, então você pode deixar o Gate URL vazio. Para os demais o campo não vem preenchido: informe o endereço que seu banco ou provedor forneceu, caso contrário o formulário de pagamento não tem para onde enviar.

As treze instituições suportadas

NestPay / Asseco (Payten): İş Bankası, Akbank, Halkbank, QNB, Şekerbank, TEB, Ziraat Bankası
Garanti GT3D: Garanti BBVA
PayFlex V4: VakıfBank
Instituições de pagamento: iyzico, PayTR, Craftgate, Sipay

Instituições sem implementação continuam na lista de bancos de propósito, marcadas com “— yakında”. Removê-las esconderia quais famílias de protocolo ainda faltam. Se a sua for uma delas, a aba Solicitação de banco é onde dizer isso.

Só a assinatura NestPay tem um teste de vetor de referência contra o exemplo publicado pelo próprio banco. Todos os outros provedores estão marcados como beta no próprio código: o fluxo está implementado conforme a documentação, mas ainda não foi verificado de ponta a ponta com uma conta de estabelecimento real naquela instituição. Esse rótulo permanece até que isso aconteça.

Instituições de pagamento não emitem cartões, então não têm lista de BINs. Você as seleciona como seu POS em vez de rotear para elas.

Webhooks — onde o pedido é realmente concluído

Todo provedor internacional precisa de um endereço no seu site, e ele tem o mesmo formato para todos eles: ?mevvpos-webhook=<provider> sobre o seu endereço principal. O valor exato é exibido em modo somente leitura na aba Bank API; clicar no campo o seleciona.

O que completa o pedido é o webhook, não o retorno do cliente ao seu site. O endereço de retorno pode ser adivinhado e um cliente pode chegar até ele sem ter pago, então um navegador chegando ali não prova nada por si só. O MevvPos nunca lê o resultado a partir do retorno: ele espera a notificação assinada ou pergunta diretamente ao provedor, servidor a servidor. Até que uma dessas duas respostas chegue, o pedido permanece pendente e uma nota do pedido registra isso.

Copie o endereço da aba Bank API.
A Mollie é a exceção e não precisa que nada seja colado em lugar nenhum: o MevvPos envia o endereço com cada pagamento que cria. Ele é omitido quando o site responde em um endereço local, porque a Mollie não conseguiria alcançá-lo de qualquer forma — durante o desenvolvimento local o resultado vem da consulta de status.
Cole-o no próprio painel do provedor exatamente como aparece. O Square calcula sua assinatura sobre o endereço de notificação junto com o corpo, então um caractere de diferença — uma barra final já basta — faz todo evento falhar na verificação, silenciosamente.
Salve o signing secret que o provedor devolve no campo extra desse provedor.
Envie um evento de teste pelo painel do provedor e verifique que um pedido realmente muda de estado.

A Mollie não assina sua notificação de forma alguma — o corpo carrega nada além de um id de pagamento. Isso parece inseguro e na verdade é mais seguro: o MevvPos não confia na notificação, ele a trata como uma campainha. Ele pega o id e pergunta diretamente à Mollie qual é o status do pagamento, e só uma resposta paid produz um evento. Um atacante pode tocar a campainha com um id inventado, mas não consegue forjar a resposta da Mollie, então uma notificação forjada nunca consegue marcar um pedido como pago. Se a Mollie não puder ser alcançada, a resposta é “não sei” e nada muda.

A assinatura do PayPal também não é verificada localmente. É uma cadeia de certificados, e um erro silencioso ao verificar uma cadeia torna a assinatura sem sentido; o PayPal publica um endpoint para isso, e qualquer coisa diferente de SUCCESS significa que o evento é ignorado.

Três regras valem para todo provedor. A resposta é sempre um 200 vazio — um evento verificado, uma duplicata e lixo recebem todos a mesma resposta, porque uma resposta diferente diria a um atacante qual tentativa chegou mais perto, e uma resposta de erro só faria o provedor tentar de novo um evento que nunca vai verificar. O PayTR é a única exceção, porque quer literalmente o texto OK e repete a notificação por horas sem ele. O mesmo evento entregue duas vezes não tem um segundo efeito. E contra qual conta um evento é verificado é lido da sua própria configuração, nunca da requisição — caso contrário um atacante poderia indicar com qual chave sua própria falsificação seria conferida.

O webhook não passa pelo endpoint do WooCommerce. Ele tem sua própria variável de consulta e é capturado antes mesmo de o tema, a página e o mecanismo de consulta rodarem — o que também explica por que funciona em um site sem WooCommerce instalado.

Roteamento baseado em BIN

Os seis primeiros dígitos de um cartão identificam o banco que o emitiu. O MevvPos compara exatamente esses seis dígitos.

A snapshot of the BIN table ships inside the plugin — 1.449 BINs across 36 banks in the current build — so routing works offline, with no account of any kind, from the moment you install it.
O Pro a atualiza semanalmente a partir dos nossos servidores. A atualização é mesclada sobre a tabela empacotada em vez de substituí-la: uma resposta parcial ou vazia nunca deve deixar uma loja sem dados de BIN.
Uma resposta com menos de cem BINs é rejeitada como implausível e não é gravada.
Os conflitos — o mesmo BIN reivindicado por dois bancos — são resolvidos do nosso lado antes de a lista ser enviada. Uma loja que os resolvesse localmente poderia contar um cartão como “nosso” e roteá-lo para outro lugar ao mesmo tempo.

Um BIN não reconhecido nunca é recusado. Ele cai no seu POS padrão. Recusar um cartão que simplesmente não temos cadastrado seria perder uma venda para proteger uma tabela de consulta.

A mesma tabela responde a uma segunda pergunta, diferente, no checkout: este cartão é do próprio banco deste POS? É isso que decide se o parcelamento é oferecido — veja abaixo.

A exatidão dos BINs não é um recurso pago. O que o Pro paga é a atualidade, não a correção: a lista empacotada é a mesma lista, apenas congelada no momento do build.

Parcelamento e comissão

As taxas são definidas por POS, do pagamento à vista até doze parcelas, na aba Parcelamento e comissão. São porcentagens: escreva 5.50 para 5,5%.

Isto funciona nas duas superfícies de finalização. Na página de blocos a tabela de prestações é desenhada pelo próprio bloco e o acréscimo é adicionado ao carrinho como uma taxa, tal como na página clássica, pelo que escolher uma prestação atualiza o total antes de a encomenda ser feita.

O parcelamento é uma instituição turca e a aba sabe disso. Enquanto um provedor internacional está selecionado, a grade de taxas não é exibida de forma alguma, e a aba diz isso em uma frase: preencher doze linhas que nunca poderiam se aplicar seria uma forma de enganar você.

0: A opção é exibida e nenhuma comissão é adicionada.
Vazio: A opção não é exibida de jeito nenhum. Vazio e zero não são a mesma coisa.

A comissão aparece no carrinho como uma taxa tributável chamada “N Taksit Komisyonu” (comissão de N parcelas), calculada sobre o total do carrinho incluindo frete e impostos.

O parcelamento só é oferecido em cartões emitidos pelo próprio banco daquele POS, e isso é imposto no servidor — não apenas escondido na interface. Um cartão de outro banco é forçado de volta ao pagamento à vista e a taxa é removida.

The ceiling is twelve in every installation — that is the limit the banks themselves apply, not a product limit. It is enforced in three places: the list the customer sees, the value that arrives with the form, and the value the engine sends to the provider. A modified form cannot buy more instalments than you offer.

O formulário de configurações sempre mostra os doze campos, qualquer que seja a sua licença. Se eles sumissem quando uma licença expirasse, salvar a página apagaria silenciosamente taxas que você já tinha informado. Os campos acima do seu limite são marcados como “Liberado no Pro” e os seus números são mantidos.

Não existe tabela de parcelamento fornecida pelo banco. As taxas são as que você informa, e a comissão de um pedido passado é calculada pela taxa que valia no dia da venda — mudar uma taxa hoje não reescreve o relatório de ontem.

O fluxo de pagamento e o tratamento do cartão

Todas as famílias turcas passam pelo 3-D Secure. Não há modo sem 3D nem definição para o desligar. Do lado internacional, o MevvPos fala EMV 3-D Secure 2: regista se o pagador foi autenticado com ou sem verificação adicional, envia o cliente para o banco quando o emissor a pede e lê o ECI para registar se a responsabilidade por chargeback foi transferida. Duas coisas que deliberadamente não faz: nunca reclama uma isenção para a qual o fornecedor não tem campo e nunca regista a responsabilidade como sua quando o fornecedor não nos comunica o resultado — «não sabemos» e «a responsabilidade é do estabelecimento» são respostas diferentes.

Fluxo por formulário: NestPay, Garanti, PayTR e Sipay: o navegador envia um formulário assinado ao banco, o cliente se autentica, e o banco retorna ao seu site.
Fluxo por servidor: VakıfBank, iyzico e Craftgate: seu servidor conversa com o provedor, obtém a página 3-D, exibe-a e conclui a venda de servidor para servidor após a autenticação.
Fluxo de redirecionamento: Stripe, PayPal, Mollie, Square, Checkout.com, Razorpay e Paystack: o MevvPos cria o pagamento através da API REST do fornecedor e envia o cliente para o endereço que o fornecedor devolve.
Fluxo de formulário com token: Authorize.Net: o provedor retorna um token em vez de um endereço, e o token é enviado (POST) para sua página hospedada como um formulário. Escrever o token em uma URL o vazaria no histórico do navegador e nos registros do servidor.

Os bancos turcos sempre retornam para um único endereço no seu site: ?wc-api=mevvpos_callback. A assinatura nesse retorno é verificada usando a chave do POS que o pedido efetivamente usou, registrada no próprio pedido — com mais de um POS, verificar com a chave errada produz um erro de hash em todos os pagamentos.

O cartão nunca chega ao seu banco de dados. Ele fica no navegador pelo tempo do redirecionamento e é removido depois. Se não estiver lá quando a página de pagamento carregar — uma nova aba, um recarregamento, armazenamento desativado, uma volta a partir do banco — um formulário de cartão visível é exibido em vez de enviar campos vazios ao banco. O formulário de cartão é visível por padrão, de propósito: um fluxo de pagamento não pode depender de o JavaScript ter rodado.

Quando o banco aprova o pagamento, o pedido é concluído mesmo se o código de status 3-D for inesperado — uma nota no pedido registra a anomalia e pede que você a confirme na própria tela do banco. Se o banco diz aprovado, o cliente já foi cobrado; recusar isso significaria “seu cartão foi cobrado mas seu pedido falhou”.

Cada tentativa registra o POS usado, o banco e o BIN do cartão, a quantidade de parcelas e a taxa, o resultado, o código e a mensagem de resposta do banco, e as referências de autorização e de transação.

Pré-autorização, links de pagamento e regras de risco

Autorizar agora, cobrar depois

Cada registo POS carrega um método de cobrança: cobrar de imediato, ou reter o valor e cobrá-lo mais tarde. Com o segundo, o dinheiro é reservado no cartão no checkout e o ecrã da encomenda ganha dois botões — cobrar (tudo, ou parte) e libertar. Cobre quando a encomenda sai; liberte quando não conseguir fornecer.

A definição só aparece onde o fornecedor realmente a suporta: a família de bancos NestPay (İşbank, Akbank, Halkbank, QNB, Şekerbank, TEB, Ziraat) mais Stripe, Authorize.Net e Checkout.com. Para todos os outros fornecedores, a opção não é sequer oferecida, em vez de ser oferecida e depois falhar na gateway.

Um link de pagamento

O ecrã Links de pagamento cria um link para um valor e, opcionalmente, uma descrição e uma validade. Quem o abrir chega ao checkout habitual da loja com um pedido pendente já criado, o que significa o mesmo encaminhamento por BIN, a mesma tabela de prestações e o mesmo passo de 3-D Secure que qualquer outro pagamento. Nada é um atalho à volta do motor de pagamento.

O token são 32 bytes aleatórios; o endereço não pode ser adivinhado a partir de outro.
O link expira na data que definir.
Funciona uma vez. Depois de a encomenda ser paga, o link deixa de abrir, pelo que uma mensagem reencaminhada não pode ser paga duas vezes.

Regras de risco

O ecrã Risco tem cinco regras, cada uma ativada e com o seu próprio limiar definido em separado. São avaliadas antes de o cartão ser enviado a qualquer fornecedor, e cada uma pode assinalar o pedido, retê-lo para análise ou recusá-lo diretamente.

Tentativas por morada — quantas tentativas de pagamento um visitante pode fazer numa janela de tempo.
Tentativas por cartão — a mesma contagem para um único cartão.
Falhas consecutivas — uma sequência de recusas seguidas.
Desfasamento de país — um cartão emitido na Turquia com morada de faturação fora da Türkiye.
Teto de valor — um total de encomenda acima do qual quer olhar primeiro.

Nenhuma morada e nenhum número de cartão é registado. O que os contadores guardam é um resumo com sal da sua própria chave do site, pelo que as regras conseguem reconhecer uma repetição sem o ecrã se tornar numa segunda base de dados de cartões. Não há impressão digital de dispositivo, nem pontuação por aprendizagem automática, nem lista negra de BIN — cinco regras que pode ler, e nada que não consiga explicar a um cliente.

Reembolsos

Para os provedores internacionais, os reembolsos são emitidos a partir da tela de pedido do WooCommerce da forma habitual — total ou parcial. O MevvPos envia o reembolso ao provedor com base na referência de pagamento registrada no pedido.

Reembolsos nunca são bloqueados pela licença. Não conseguir devolver o dinheiro a um cliente não é algo que um lembrete de renovação tenha permissão para causar, e na maioria dos países é, além disso, uma obrigação legal.

O POS virtual de banco turco ainda não pode ser reembolsado pelo WordPress, e o MevvPos diz isso em vez de fingir o contrário. Reembolse a transação pela própria tela do seu banco. Reportar sucesso silenciosamente faria o WooCommerce marcar o pedido como reembolsado enquanto o dinheiro ficava parado no banco — um registro contábil errado custa muito mais caro que um botão que não funciona.

Um reembolso precisa da referência de pagamento que o provedor devolveu. Um pedido feito antes de essa referência ser registrada, ou um cuja conta de provedor tenha sido excluída depois, não pode ser reembolsado pelo plugin.

Relatórios

A aba Relatórios mostra a receita, as transações bem-sucedidas, a taxa de sucesso e a divisão entre pagamento à vista e parcelado, com um gráfico diário. As transações que ainda aguardam o retorno do banco são contadas à parte e ficam de fora da taxa de sucesso.

The revenue summary covers 7, 30 or 90 days in every installation. The Pro add-on adds three breakdowns on top of it:

Carga de parcelamento e comissão — quantidade, receita e encargo de comissão por faixa de parcelamento.
Detalhamento por POS e banco — receita, sucessos, falhas e taxa de sucesso para cada POS e para cada banco emissor.
Distribuição dos códigos de recusa — com exportação CSV. Um código de recusa que se repete aponta para algo que você pode consertar: saldo insuficiente é problema do cliente, mas erros de verificação 3-D e de configuração do POS são seus.

Os dados por trás dos relatórios são coletados pelo plugin gratuito, então o histórico continua se acumulando tenha você o Pro ou não. Tem de ser assim: dados passados não podem ser gerados retroativamente quando você faz o upgrade.

Uma loja recém-instalada não tem gráfico. O registro começa com o plugin, e a tela se preenche após a primeira tentativa de pagamento.

Usando o motor sem o WooCommerce

O gateway do WooCommerce agora é apenas um consumidor do motor de pagamento, não o motor em si. O motor não sabe nada sobre pedidos, carrinhos ou sessões: você entrega a ele uma intenção de pagamento — um valor como número inteiro de unidades menores, uma moeda, uma referência e os endereços de retorno — e ele devolve ou um formulário para enviar (POST) ou um endereço para redirecionar. Um plugin de formulário, um plugin de reservas ou o seu próprio código pode operá-lo da mesma forma que o checkout faz.

MevvPos_Payment_Engine::start() inicia um pagamento e retorna o que o navegador deve fazer em seguida.
MevvPos_Payment_Engine::handle_webhook() é o único caminho que altera o estado de um pagamento. Um evento cuja assinatura não é verificada não muda nada e é registrado.
MevvPos_Payment_Engine::webhook_url() monta o endereço que você cola no painel do provedor.
O teto de parcelas também é aplicado dentro do motor, como última linha de defesa — a tela que chamou pode ter sido renderizada antes da licença expirar.

Se você registrou seu próprio provedor por meio do filtro mevvpos_providers antes da versão 4.0.0, ele agora recebe uma intenção de pagamento em vez de um WC_Order. As requisições e assinaturas das sete famílias turcas não mudaram, então as configurações de POS já existentes continuam funcionando sem alteração.

Solicitações de banco e suporte

Solicitação de banco: Lista todas as instituições que ainda não foram implementadas, com o motivo: ou a família de protocolo não foi determinada, ou a família é conhecida e estamos aguardando a documentação. Você pode abrir uma solicitação para uma delas, ou indicar uma instituição que não esteja na lista.
Suporte: Um assunto, o POS ou banco envolvido, o que acontece quando você faz o quê, e a mensagem de erro que o banco exibiu.

O formulário de suporte pede que você não inclua número de cartão nem código de segurança. Eles nunca são necessários para diagnosticar um problema de pagamento, e nenhum dado de pagamento ou de cartão é enviado com qualquer um dos formulários.

O plugin gratuito entra em contato com os nossos servidores apenas quando você aperta um desses botões. Nada é enviado em um cronograma e não há nenhuma chamada de licença na edição gratuita.

Free e Pro

Nothing in the free plugin is locked, limited or counted. Every Turkish institution, every international provider, 3-D Secure, hosted-page checkout, wallets, multi-currency, currency and BIN routing, as many POS accounts as you have merchant agreements, instalments to twelve, test mode, refunds, pre-authorisation, payment links, the risk rules and the 7 / 30 / 90 day revenue report all work with no key and no account. Pro is a separate plugin whose code is not in the free package at all — it adds capabilities rather than raising a ceiling.

Free: Everything on this page unless it says otherwise: unlimited provider and POS accounts with BIN and currency routing, instalments to twelve, the 7 / 30 / 90 day revenue report, the packaged BIN table, pre-authorisation, payment links, risk rules, refunds and unlimited transaction volume. Apple Pay and Google Pay too, because they appear on the provider’s hosted page by themselves.
Pro: Recurring payments and subscription billing, the mandate store, stored payment authorisations in My Account, SCA exemption requests, the POS / bank / instalment / decline-code breakdowns with CSV export, and a weekly live BIN refresh. A separate plugin, downloaded from your account here — it is not on WordPress.org.

Multi-currency and routing by currency are both free. They were briefly sold with Pro; charging for the ability to point a euro order at the euro account was pricing a limitation rather than a capability, and it is gone.

Quando uma licença expira ou está ausente:

Nothing in the free plugin changes. It does not ask about licences at all — the question was removed from that package in 4.9.1 — so every account, every instalment plan, every route and the whole revenue report keep working exactly as before.
Your store keeps taking payments. There is no licence check anywhere on the payment path. Cutting off a shop’s revenue is not an acceptable way to send a renewal reminder.
Os reembolsos continuam funcionando, porque não são bloqueados de forma alguma.
Recurring charges already scheduled stop being taken, and the subscription screens go quiet. Mandates and stored authorisations are never deleted; they resume on renewal.
The breakdowns and CSV export stop. The 7 / 30 / 90 day report underneath them is in the free plugin and stays. Collected history is not deleted.
A atualização ao vivo dos BINs para; a tabela empacotada continua funcionando.

Se os nossos servidores estiverem inacessíveis, uma licença ativa continua funcionando por sete dias com base na última verificação bem-sucedida. Mas uma licença cuja própria data de validade já passou é lida como expirada de qualquer forma — do contrário, bloquear o nosso endereço seria uma maneira de estender uma licença por uma semana.

Atualizações

O plugin Pro traz um atualizador vinculado à sua licença. Precisa ter: o Pro não é publicado no WordPress.org, então não há de onde o WordPress aprender que existe uma nova versão. Com uma licença ativa, uma atualização do Pro aparece na tela de plugins como qualquer outra.

O plugin gratuito anuncia agora também as suas próprias atualizações. Pergunta ao nosso servidor se existe uma versão mais recente e entrega a resposta ao próprio fluxo de atualização do WordPress, pelo que uma nova versão aparece no ecrã de plugins com um botão Atualizar vulgar, em vez de esperar que alguém descarregue um zip à mão. O pedido leva apenas o nome do pacote e a versão instalada — sem endereço do site, sem endereço de e-mail, sem chave de licença, sem inventário de plugins. Como nada nele o identifica, a confiança assenta inteiramente na assinatura: a resposta é assinada com a nossa chave Ed25519, e uma resposta sem assinatura, mal assinada, repetida a partir de um carimbo temporal antigo ou que aponte a transferência para outro anfitrião que não o nosso é descartada sem tocar no site. Os seus registos de POS, credenciais e histórico recolhido vivem nas opções do WordPress e nos metadados da encomenda, e uma atualização nunca lhes toca.

Quando algo não funciona

O banco recusa todos os pagamentos sem nenhuma mensagem útil: Quase sempre é a assinatura. Uma assinatura errada não gera erro em lugar nenhum — o banco simplesmente recusa. Verifique o número de estabelecimento, a chave da loja e quaisquer credenciais extras daquela família: todas entram na assinatura. Um teste útil é que os bancos respondem de forma diferente a um erro de assinatura e a um cartão inválido; receber uma mensagem de “cartão inválido” significa que sua assinatura está certa.
“Erro de hash” no retorno, com mais de um POS: O retorno é uma requisição separada, sem sessão. O MevvPos registra qual POS um pedido usou e verifica com aquela chave. Se você apagou o registro de POS pelo qual um pedido foi pago, a verificação recai no POS padrão e pode falhar.
O cliente paga no Stripe ou no PayPal, mas o pedido permanece pendente: O endereço de webhook não está acessível ou não está registrado. O pedido é completado pela notificação, não pelo retorno do cliente, então um webhook ausente parece exatamente igual a um cliente que nunca pagou. Verifique se o endereço na aba Bank API é o mesmo salvo no painel do provedor, e se o evento de teste do provedor chega.
Todos os eventos do Square são rejeitados: O Square assina o endereço de notificação junto com o corpo. O endereço registrado no Square precisa coincidir caractere por caractere com o da aba Bank API — uma barra final, http em vez de https, ou um www que um lado tem e o outro não já basta.
Os eventos do Authorize.Net nunca verificam: A Signature key é um valor separado da Transaction Key e os dois são fáceis de trocar entre si. Os webhooks são verificados apenas com a Signature key.
O cliente chega a uma página de pagamento em branco, ou o botão Öde (Pagar) não faz nada: Um plugin de cache ou de otimização está adiando scripts. No LiteSpeed, exclua mevvpos, jquery e os scripts de front-end do WooCommerce da lista de atraso. O formulário de cartão é exibido por padrão para que o fluxo continue funcionando, mas o redirecionamento automático não.
O pedido fica “pendente” depois de um pagamento bem-sucedido: O banco ou o provedor não alcançou o endereço de callback. Verifique se ?wc-api=mevvpos_callback é acessível de fora — um modo de manutenção, uma restrição de IP ou uma barreira de login na frente do site vão bloqueá-lo.
O formulário de pagamento é enviado para a mesma página: O campo Gate URL está vazio para um banco cujo endereço não vem preenchido. Informe o endereço que seu banco ou provedor forneceu.
O modo de teste está ligado, mas o pagamento continua indo para o banco real: O modo de teste interrompe o redirecionamento automático e mostra a requisição a você; ele não reescreve o endereço do gateway para os bancos NestPay. Coloque o endereço de teste do seu banco em Gate URL enquanto estiver testando. No Stripe e na Mollie a alternância também não muda o endereço — ali é a chave de teste que seleciona o sandbox.
O parcelamento não aparece: Either the rate for that count is empty rather than zero, the card is from another bank, or the selected provider is an international one and has no instalments at all.
Os cartões vão para o POS errado depois de uma atualização: Versões antigas traziam faixas de BIN escritas à mão que estavam parcialmente erradas. Verifique se cada POS está arquivado sob o banco em que ele realmente está.
A tela de administração parece sem estilo, ou uma correção não aparece: Um cache de navegador desatualizado. Recarregue a página contornando o cache.

Limites

A lista abaixo é deliberada. Nada disso é um bug.

Sem reembolsos para o POS virtual de bancos turcos. Nenhuma família turca inclui uma chamada de reembolso; reembolse a partir do ecrã do seu próprio banco. Os os fornecedores internacionais fazem-no, e o WooCommerce mostra o botão de reembolso para eles.
The updater depends on where you got the plugin. The build downloaded from mevvsoft.com updates itself from our servers. The build published on WordPress.org does not carry that code at all — a plugin hosted there must be updated through WordPress.org, so the two packages differ in exactly this one file.
Os pagamentos recorrentes funcionam apenas com os fornecedores internacionais e não há seletor de cartões guardados. Uma autorização de cobrança guardada é criada, renovada, repetida e marcada como vencida, e um produto WooCommerce Subscriptions configura-a sem escrever código. O que falta: as famílias de POS virtual dos bancos turcos não a suportam, o comprador não pode escolher um cartão guardado na finalização, e não há calendário de cobrança nem cancelamento pelo painel.
A pré-autorização existe, mas não em todo o lado. Um POS pode reter o valor e cobrá-lo mais tarde — total ou parcialmente — a partir do ecrã da encomenda, ou libertá-lo. Só a família de bancos NestPay, Stripe, Authorize.Net e Checkout.com a suportam; todos os outros fornecedores são venda direta e a definição não lhes é mostrada.
No rule-based routing. Routing is by currency and issuing bank only — not by amount, card brand or country.
Routing asks the currency first and the issuing bank second, in every installation. What is still missing is everything past that: no failover to a second account, no cascading retry, and no routing by amount, card brand or country.
Ambos os checkouts são suportados. O formulário de pagamento clássico e o bloco de Checkout do WooCommerce são ambos servidos, e a tabela de prestações e o respetivo agravamento comportam-se da mesma forma em qualquer um. O bloco escreve o BIN e as prestações escolhidas através da Store API, pelo que o agravamento é calculado pelo mesmo código que na página clássica.
O 3D Pay Hosting foi rejeitado de propósito. A página hospedada remove o escopo PCI, mas também remove o BIN e a tabela de parcelas — e todo o valor do lado da Türkiye está no roteamento que eles tornam possível. Os provedores internacionais são hospedados precisamente porque ali não há nada para rotear.
Sem editor de BIN. A tabela é gerenciada por nós e mesclada com a atualização ao vivo; não há tela para editá-la à mão.
Vinte e seis instituições estão listadas mas não implementadas. Elas continuam visíveis para que a lacuna fique visível.
Todos os provedores exceto o NestPay são autodeclarados beta até serem verificados de ponta a ponta com uma conta de estabelecimento real.
As abas ficam dentro da página. Os itens da barra lateral abrem a tela do MevvPos; troque de aba na própria página.

O que nunca é armazenado, de forma alguma: o número do cartão, a data de validade e o código de segurança. No lado da Türkiye, o único dado de cartão mantido são os primeiros seis dígitos e o banco que eles identificam; com os provedores internacionais, nem isso, porque o cartão nunca é digitado no seu site. Armazenar o código de segurança é proibido em toda e qualquer circunstância, e até um mascarado vaza seu comprimento.

Um único motor: o POS virtual dos bancos turcos e os provedores internacionais.