Inicie o prompt de comando como administrador.
Execute o comando abaixo.
net stop w3svc
Depois o comando
net stop iisadmin
Pronto, execute o xampp e verifique se o problema foi resolvido.
Esse projeto não é algo novo, tenho disponibilizado no GitHub desde 2017, porém nunca divulguei abertamente o repositório. Após conversar com algumas pessoas, pensei: Já que está público para o mundo, porque não divulgar?
Para usar as collections, basta baixar o projeto no repositório pagseguroXpostman, importar no postman, e ao final incluir seu e-mail e token nas variáveis locais, e pronto… tudo está funcionando.
]]>A postagem mais antiga é de 01/04/19, onde a galera falava referente o número de caracteres do token passar de 32 para 100 caracteres.
Fizemos uma análise no novo token e pudemos temos alguns pontos:
Um ponto que não conseguimos validar foi a estrutura do token de sandbox, para mim ela continua a 32 caracteres, porém o sandbox não permite alterar o token, imagino que seja por isso que não é 100. Mas e as novas contas, irá vir com a estrutura de token do sandbox com 100 ou 32 caracteres.
Agora fico com a pulga atrás da orelha para saber qual serviço o PagSeguro está para lançar que forçou a mudança da estrutura do token tão repentinamente quem nem deu tempo de avisar aos usuários. Alguém arrisca um palpite?
]]>Inicie o prompt de comando como administrador.
Execute o comando abaixo.
net stop w3svc
Depois o comando
net stop iisadmin
Pronto, execute o xampp e verifique se o problema foi resolvido.
Ao acessar qualquer página da documentação do PagSeguro, agora aparece um botão no canto inferior esquerdo com a pergunta “Posso ajudar?”. Ao clicar neste botão é iniciado um chat com um bot, o qual dá para tirar algumas dúvidas simples, e ao final da conversa, o bot questiona se conseguiu ajudar, se você responder não, um formulário secreto será exibido dando acesso a abertura de um chamado com uma pessoa real dentro do PagSeguro. Veja animação abaixo com o fluxo.
Quer testar? basta acessar a documentação em https://devs.pagseguro.uol.com.br/docs/introducao e você já terá o botão “mágico” liberado.
E vocês o que acharam da novidade?
Comente abaixo como foi a experiência com o PagSeguro com essa nova funcionalidade.
Para entender o motivo disso, precisamos entender o que é um intermediador de pagamentos.
O Intermediador de pagamentos é uma solução para receber e enviar pagamentos com flexibilidade e segurança.
Isso significa que a ideia do intermediador de pagamentos, é facilitar de uma forma onde você precise programar o
mínimo e ter o máximo de ferramentas no momento de incluir opções de pagamento em seu site.
Você não precisa concordar ou discordar se ele faz esse papel, só precisa ter ciência do que ele quer
fazer.
Agora que entendemos o intermediador de pagamentos, precisamos entender que, ao colocar o intermediador como solução de pagamento, estamos incluido uma série de sistemas embutidos.
Parei no AntiFraude de propósito, ele é o motivo deste post ser escrito. Sim, suas transações são canceladas quando você testa em produção por conta do AntiFraude (na maioria das vezes não é possivel desativar esse serviço).
Dependendo do intermediador que você estiver utilizando, ele pode falar explicitamente ou informar que foi por motivos interno. Usarei o PagSeguro como exemplo.
Consultando os detalhes detalhes de uma transação - Seja pela API de notificações ou API de consulta por código de transação - procure por <transaction><cancellationSource> , (linha 8 do exemplo) .
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>
<transaction>
<date>2018-02-15T13:01:15.000-02:00</date>
<code>0BED7D1B-DC00-4DE8-8828-082F8FCC7D55</code>
<reference>REF1234</reference>
<type>1</type>
<status>7</status>
<cancellationSource>INTERNAL</cancellationSource>
<lastEventDate>2018-02-15T13:01:16.000-02:00</lastEventDate>
<paymentMethod>
<type>1</type>
<code>101</code>
</paymentMethod>
<!-- Código reduzido, para economizar espaço -->
</transaction>
O exemplo foi reduzido para ocupar menos espaço, porém você pode ver o XML de exemplo completo clicando aqui.
O campo cancellationSource, significa a origem do cancelamento. Sempre que a origem do cancelamento for interna (Internal), significa que o antifraude barrou essa transação.
Cada intermediador terá sua peculiaridade, entre em contato com o suporte e procure entender como funciona no seu. Aproveite e poste nos comentários afim de ajudar o próximo que estiver pesquisando.
Não sabemos ao certo como o AntiFraude dos intermediadores funcionam, caso você pergunte no SAC, eles não irão responder, por motivos de segurança. Eles acreditam que se todos tiverem ciência dos critérios do AntiFraude, a segurança das transações fica comprometida, e alguém mal intencionado poderá burlar esse sistema e fazer compras indevidas.
Juntamos algumas dicas espalhadas pela intenet e vou citar algumas aqui:
Cada intermediador de pagamento tem um termo/regras de uso. Lá existem uma série de itens a serem cumpridos, como por exemplo não vender drogas, órgãos... Leia todos itens, a inteligência do AntiFraude pode usar alguma regras dessas para permitir ou não a venda.
Diversos campos são de preenchimento obrigatórios na requisição de pagamento, muitas vezes para pular alguns passos o programador pega alguns desses campos e deixa com valor padrão e assim o comprador não precisa preencher. O ponto é: O AntiFraude pega o padrão e classificar como uma fraude, negando tudo.
Lembre, na internet tudo se conversa, se esse mesmo comprador realizou alguma compra recentemente online usando dados totalmente diferentes do usado na compra atual, o AntiFraude pode bloquear a transação também.
Maioria dos sitemas podem verificar se não existem restrições no nome da pessoa, e/ou se aquele CPF já foi usado anteriormente para fraude.
Em todo cadastro no intermediador de pagamento, você vai precisar categorizar seu comércio, é importante preencher corretamente esse item. Caso contrário suas vendas entrará fora do padrão o que acabará dando cancelamento indevido.
Normalmente você faz uma compra no site e só volta lá depois de um tempo, se no meio de seus testes, você faz duas, três, ou seja lá quantos testes, o AntiFraude pode pegar seu IP e cookie (ou sabe lá Deus o que ele pega) e detectar um padrão diferente e realizar o bloqueio, então testes em produção apenas com usuários reais, ou de locais e ambientes diferentes.
Você já caiu em algum ciclo onde o AntiFraude cancelava suas transações? O que você fez para contornar isso?
]]>A finalidade deste post não é acusar, muito menos provar nada a ninguém e sim de manter informado o administrador de sistema o status do serviço afim de que em problemas futuros possa ser identificado a origem e contornado mais rapidamente.
No momento não está disponível consulta para todas APIs, conforme sobra tempo irei atualizando esse post com novos links. Fique a vontade de comentar quais serviços vocês querem que sejam incluidos que posso alterar a prioridade na fila.
A ideia dá pra ser acompanhada abaixo:
Não temos nenhum relacionamento com o time de desenvolvimento do PagSeguro, então se algum serviço não estiver funcionando para sua aplicação, não comente aqui, prefira entrar em contato direto com eles.
Sendo asssim, utilize os comentários abaixo apenas para feedbacks e sugestões.
Esse post será reeditado para mais um detalhamento melhor. Mas só para falar que o PagSeguro acabou de lançar um serviço de geração de boletos.
Ainda sabemos pouca coisa sobre o serviço mas já conseguimos entender alguns benefícios:
Quanto às vantagens que citei acima, existe algumas limitações, imagino que pelo fato de ser algo novo e eles precisarem controlar melhor para em caso de problemas, conseguir contornar mais rápidamente.
Nesse post não irei falar sobre a API necessariamente, mas irei compartilhar um exemplo do nosso SDK que já utiliza essa API.
O projeto pode ser baixado em pagseguro-php-sdk e o exemplo do boleto está em '/example/boleto.php'.
Acompanhe aqui o health check das APIs do PagSeguro.
]]>Aqui não falaremos de nenhuma API nova, e sim de um complemento para as APIs que já existem.
Quando você estiver enviando no formato x-www-form-urlencoded, basta adicionar mas um parâmetro
1
shippingAddressRequired=false
Quando você estiver enviando no formato XML, basta adicionar mas um nó dentro do nó checkout:
1
<shippingAddressRequired>false</shippingAddressRequired>
Essa ferramenta não faz o upload do seu arquivo, é necessário que ele esteja hospedado em algum lugar. O serviço de pre-visualização estamos utilizando o do Google.
]]>Essa ferramenta utiliza uma das APIs de consulta do PagSeguro para realizar a validação, não fazemos nenhuma alteração na sua conta, pode ficar tranquilo.
]]>