Patty

Acho que as pessoas só se ligam nos nomes, nas marcas. Não fazem a menor noção da qualidade do serviço e do atendimento. Devem achar que este é o melhor serviço e o maior atendimento, pq é a maior e mais famosa. Então nem se preocupam em procurar outros e comparar. É a mágica do marketing.

Obrigada por responder, Thiago. E é isso que todo mundo vai fazer agora? Usar terceirizados?? Ninguém mais vai usar boleto direto com o banco??

Ninguém??? Achei que este seria um assunto que todo mundo estaria interessado em discutir.... Ninguém está ou vai continuar trabalhando com boleto???

Olá, pessoal. Estou entrando na discussão um pouco atrasada... hehehe Sei que o tópico é um pouco antigo, mas acho que a discussão ainda é bem atual, né, e eu queria saber o que vocês estão pensando em fazer quanto a esta questão dos boletos? Sei que existe a alternativa dos intermediários, mas acho que seria importante ter a opção direta com os bancos, como ainda se tem agora. Então, neste caso, quais são as idéias para e-commerce/gerenciadores tipo WHMCS/emissão de boletos online? Como vocês estão lidando com isso?

Eu uso há mais de 3 anos e recomendo. Atendimento rápido, ótimos preços, equipamento de ponta, links super-rápidos (comparados com outros nos EUA).

Eles não tem mesmo, Edvan. O suporte deles nunca prestou. Por isso que a gente tem que se virar. Eu ainda bato na tecla de que pode ser resolvido no módulo mesmo, pois outras integrações funcionam com a mesma API antiga, então é coisa do módulo mesmo. Eu estou sem programador no momento, senão, já tinha resolvido isso. Por isso estou aqui pra ver se alguém conseguiu resolver, pois muita gente usa este módulo do Carlo. Kd ele, por falar nisso??

Alguém sabe como criar um log de debug neste módulo do Carlo?? Notei que na fatura registra os posts dos pagamentos via boleto (Aguardando Pagto, em 01/04/2015 16:33:24, via Boleto, ID: E5F76753899B443392CAB936921647F3), então ele tá recebendo os posts sim. O problema é quando o pagamento é via cartão, que aí não registra o post da transação. Alguém sabe dizer por que e como resolver isso?? A API antiga funciona ainda sim, acredito que é algum bugzinho que não deve ser difícil resolver.

Entendi. É no mínimo estranho. Mas vindo do PagSeguro, não é surpresa nenhuma, né.... ô servicinho ruim da peste!!! Pior que a gente precisa usar, pois o nome UOL por trás tem peso, né.... Vlw, Edvan! ;)

Ei, Edvan. Não acho que é só coincidência não. Eu estava usando a v5.2.17 e funcionava 100%. Enquanto isso, um cliente usando a nova v5.3.12 tb estava com este problema. Daí eu atualizo pra v5.3.12 e deixa de funcionar. Por outro lado, nas lojas osCommerce não está havendo problema algum, e os módulos são veeeeelhos que só! rs Acho que é alguma coisa na nova versão do WHMCS sim. Lembra que há alguns meses atrás eles lançaram um patch de segurança relacionado à API deles que poderia afetar alguns módulos de pagamento? Acho que tem alguma coisa a ver. Ninguém conseguiu resolver este problema ainda??

Revivendo a discussão... rs Eu uso o módulo do Carlo e sempre funcionou o retorno automático 100%! Até atualizar para a versão 5.3.12 Alguém já conseguiu descobrir por que e corrigir este problema?

Meu, vc tem coragem de pegar o módulo desenvolvido pelo Carlo Schneider, tirar os créditos dele e colocar os seus??? Vergonhoso!!! Se vc mudou alguma coisa (que vc não mudou), tenha pelo menos a decência de manter os créditos do autor original. * @ Módulo PagSeguro com Retorno Automático v0.2 * @ Módulo desenvolvido por: Carlo Schneider * @ http://whmcs.hostsul.com/ * @ Módulo PagSeguro com Retorno Automático v1.2 * @ Módulo desenvolvido por: Luciana Mattos e Thiago Sabaia * @ http://www.superthost.com.br/

Só trocar o split por explode. Este erro acontece nas versões 5.3 e superiores do PHP

Rubens, vc é um gênio!!!! Era isso mesmo!!! Eu copiei de um destes tutoriais repetidos aqui do fórum, algum deles deve ter juntado o Response Status Brincadeira, viu!! Desde ontem à noite por conta disso! Um milhão de obrigados pra vc!! Valeu messsssss!!! Te devo uma! :) :) :)

Sobre o grep ".br|" whoisservers.php, só retornou as entradas do /brdomaincheck Não tem mais nada com .br

Status do domínio 'djdji67u5.com.br': <br /><br />Query ID: 2465500086<br /> Domain name: djdji67u5.com.br<br /> Response Status: 0 (Available)<br />

Aparece que está registrado, não importa que domínio seja com extensão .br Testei com este: djdji67u5.com.br Domínios internacionais retornam a consulta corretamente. Mais alguma idéia, Rubens? Brigadão pela ajuda e paciência, viu...

Apareceu isso: Status do domínio 'registro.br': <br /><br />Query ID: 2602370065<br /> Domain name: registro.br<br /> Response Status: 2 (Registered)<br /> Expiration Date: Exempt from payment<br /> Publication Status: published<br /> Nameservers: <br /> a.dns.br<br /> b.dns.br<br /> c.dns.br<br /> d.dns.br<br /> e.dns.br<br />

Troquei o path do cookie para "cookie_file" => "/home/user/tmp/isavail-cookie.txt", e agora o cookie foi sobrescrito, finalmente! Mas a consulta continua dando como domínio já registrado. Isso pq estou usando nomes malucos como asndfjfieui54679.com.br :D O whoisserver.php está como .com.br|http://www.meudominio.com/brdomaincheck.php?domain=|HTTPREQUEST-ResponseStatus: 0 (Available) e por aí vai. Cheguei até a adicionar o IP do registro.br na API do WHMCS, conferi a porta 43 no firewall, tudo certo. O que mais pode estar errado pra que isso não funcione???

Obrigada, Rubens. Conferi aqui e o cookie está no diretório tmp (CHMOD 700) acima do public_html e com permissão 666. Mas nada acontece nele, continua com o valor original 00000000000000000000 e as consultas continuam retornando que o domínio já está registrado. Refiz toda a instalação, IP liberado no servidor, tudo aparentemente certo. O que mais pode ser? Este é o arquivo que estou usando (não sei se faz diferença, mas a versão do PHP é 5.2.17): <?php # ${copyright}$ # $Id: brdomaincheck.php 70 2013-01-13 21:44:00Z rubens $ require "Avail.php"; function check_domain_availability($fqdn, $parameters) { $client = new AvailClient(); $client->setParam($parameters); $response = $client->send_query($fqdn); return $response; } $atrib = array( "lang" => 1, # PT (EN = 0) "server" => "registro.br", "port" => 43, "cookie_file" => "/tmp/isavail-cookie.txt", "ip" => "", "suggest" => 0, # No domain suggestions ); $fqdn = $_GET["domain"];; $domain_info = check_domain_availability($fqdn, $atrib); echo "Status do domínio '{$fqdn}': <br /><br />"; echo nl2br($domain_info); ?>

Olá, Rubens. Não há duplicidade no whoisservers.php não. Removi todas as entradas anteriores e coloquei as novas de acordo com as instruções do tutorial. Me tira uma dúvida, por favor: o arquivo do cookie deve ficar no diretório public_html, junto com os arquivos Avail.php e brdomaincheck.php, ou todos os arquivos devem ficar no diretório do WHMCS? Acho que pode ser uma questão de path dos arquivos. Brigadim pela atenção. ;)

Ei, pessoal. Isso ainda está valendo? Estou usando a versão 5.2.17 do WHMCS e não consigo fazer funcionar de jeito nenhum! IP liberado, arquivo do cookie criado, já tentei com os arquivos no public_html e tb dentro do diretório do WHMCS, mas não funciona nem a pau! Continua dando que o domínio já está registrado. Alguma luz, please???

Realmente é muito trabalhoso atualizar toda hora, e mais frustrante ainda quando ao invés de melhorar, piora! Mas eu ainda acho que o WHMCS é o melhor do seu gênero, e acho que o Matt, apesar de às vezes botar os pés pelas mãos ao querer abraçar o mundo, é um grande profissional e muito sério. Acredito que ele quer poder fazer o melhor, mas com a demanda do crescimento e volume de clientes, ele provavelmente não tem mais tempo de fazer tudo ele mesmo com o cuidado que ele tinha antes, e deve estar delegando muita coisa para outros. Aí acaba dando nisso. Mas acho que eles vão se encontrar e os problemas serão resolvidos. É só ter um pouquinho de paciência e não correr pra atualizar sempre que sair uma nova versão. Eu costumo às vezes esperar até alguns meses para ter certeza de que tudo vai estar nos eixos antes de fazer uma atualização.

Parabéns pelo excelente trabalho e por disponibilizar gratuitamente, rapazes!! Um trabalho que poderia muito bem ser cobrado! Realmente, vcs estão de parabéns! :) Quando tiver um tempinho, vou testar com a Caixa e posto aqui os resultados. Valeu messss!! :)

Vamos esperar que esta realmente conserte a bagunça causada pela 5.2.1 e 5.2.2 Eu é que não vou atualizar agora, vou esperar pra ver... hehehe

Caixa SIGCB: R$ 1,30 a R$ 2,70 em São Paulo (PF) Itaú: R$ 3,09 carteira 175 em Praia Grande/SP (PJ)