Pagamentos Automáticos v2.0.0 - Workshop Open Finance Brasil (17/12/2024)

pessoal acho que eu vou dar início aqui
até para não atrapalhar a agenda de
vocês e a gente conseguir terminar tempo
então Primeiramente boa tarde aqui a
todos isso aqui é mais um workshop
ministrado pela estrutura do Open
finance do Brasil Então aqui o objetivo
hoje a gente falar um pouco sobre a nova
versão da Page de pagamentos automáticos
Então antes de entrar sobre a agenda em
si no workshop em si só dois recados
aqui importantes pessoal o primeiro é
esse workshop aqui ele tá sendo gravado
Então a gente vai pegar essa gravação e
vai colocar o a gravação do workshop no
YouTube do Open Finds Brasil o link pro
canal do YouTube tá aqui no chat também
no workshop e o segundo recado é eh se
tiver tempo no final a gente vai abrir
um espaço para tirar as dúvidas aqui de
de todo mundo mas durante a própria
apresentação aqui do workshop durante a
apresentação dos temas a gente Peg de se
vocês tiverem algumas dúvidas colocar
aqui no chat vai ter o pessoal
aqui de olho para responder às dúvidas
de vocês de novo se tiver um espaço no
futuro ainda sobrar um tempinho a gente
vai abrir para tirar as eventuais
dúvidas pendentes de todo mundo então
dando aqui continuação
eh falando sobre os apresentadores aqui
temos José e wend são membros ali do GT
serviços na dto do PF Brasil o bresler
vai falar pra gente sobre de experiência
de usuário envolvido GT de X também o
Christian que é que é da r que é o nosso
fornecedor responsável pelo motor de
conformidade funcional eu USI aqui algo
também da dto muito mais atrelado ali a
ao Squad sandbox então eu são os
apresentadores falando sobre a agenda
desse workshop aqui em si ele tá
dividido em Cinco partes né então
primeiro a gente fala sobre api em si um
comportamento funcional depois a gente
vai entrar na segunda parte um pouco
mais técnico mais dentro da api a
terceira parte a gente vai falar sobre a
experiência do usuário sim Então como
que vai vai ser essa jornada que que já
está definido quarto a gente vai falar
sobre o motor de conformidade funcional
o que que teve de atualização como que
vai ser a execução desses testes e por
último o que que de fato a gente espera
das instituições Então as
responsabilidades das detentoras e das
iniciadoras em si então H sem mais
delongas aqui eu já passo a palavra para
o Wendel para já entrar um pouco mais
sobre fazer essa introdução sobre essa
nova versão dess então fica à vontade aí
wendo obrigado Iago Obrigado aí pela
pela introdução eh primeiro Quero
Agradecer aqui né em nome do do grupo de
produtos da dto eh algumas pessoas que
ajudam a gente aqui a construção desse
dessa dessa funcionalidade assim desse
produto que é o próprio GT serviços ali
né na no papel da Coordenação os
parceiros envolvidos e o time do
secretariado também que que apoia a
gente aqui para seguir no nesse
desenvolvimento Mas vamos vamos lá sem
sem mais delongas Podemos seguir aqui
obrigado Iago acho que a primeiro slide
aqui é para dar mais um Panorama geral
para vocês aqui turma sobre a linha do
tempo né onde a gente começou quando a
gente começou e quando a gente pretende
terminar aqui o todo o desenvolvimento
do produto então em junho de 23 o banco
central ele cria ali né as diretrizes
sobre o pix automático em agosto a a
estrutura ela faz a primeira opação ali
do do cronograma em CD A princípio o
antigo CD e não como ca hoje né em
novembro a gente tem uma pausa ali eh no
desenvolvimento porque algumas das
informações que eram essenciais pro
nosso
desenvolvimento tiveram que aguardar ali
alguns inputs da Trilha do pix né então
que era um catálogo de mensageria o guia
deux pra gente conseguir desenvolver em
agosto eh de 2024 o banco central lança
ali algumas in né essas três Ines a in
508 a 511 e A 513 e contempla ali as
informações que a gente precisava Para
seguir o desenvolvimento aqui na do
nosso
lado em novembro agora de de 24 a gente
constrói um novo cronograma ali com os
ajustes
eh com todas os ajustes necessários
paraa gente poder fazer a entrega do
produto e apresenta no no CD até então
né eh a gente apresenta essa informação
no CD agora como ca em dezembro de 24 a
gente faz o lançamento da nossa versão
Beta em março de
2025 a gente tem ali como objetivo fazer
o lanamento da versão estável do produto
em abril de 25 nós iniciamos o piloto
ali vai ser algo muito parecido eh do
que tá sendo adotado hoje para a jornada
sem redirecionamento
toda a definição do do piloto ali as
regras elas ainda vão ser construídas e
apresentadas a posterior aqui pro
ecossistema e em junho de 2025 entramos
aqui com o go Live paraa entrega aqui do
do produto em si pro mercado como um
todo tá então acho que esse aqui é um
Panorama Geral do que a gente tem aqui
pro desenvolvimento pode seguir aí por
favor legal acho que esse outro slide
aqui ele tenta sintetizar alguma as
questões ali que eh sobre o Nosso
propósito aqui no no desenvolvimento né
então Eh o que que é o pix automático né
o por ele surgiu Qual o problema que a
gente tá tentando solucionar E quem deve
oferecer esse produto aqui pro pros
participantes né então o que que é o
Pixel automático o Pixel automático ele
é um serviço que permite programar ali
pagamentos recorrentes autorizados pelo
pelo pagador com volumes fixos ou
variáveis de forma automatizada com
apenas um consentimento Então acho que
esse é o o grande diferencial que a
gente tem aqui no nosso desenvolvimento
Por que que ele surgiu né ele surgiu
para facilitar ali pagamentos
recorrentes Então são os diversos casos
de usos que foram ventilados pelo
próprio regulador pelo que a mídia vem
apresentando ali da sua aplicabilidade
como por exemplo pagamento de contas de
energia telefone Academia Escola
Condomínio Entre outros né
Mas qual o problema que ele pretende
resolver aqui né e ele pode ser
utilizado assim em múltiplos modelos de
negócio e aplicado em diversos setores
eh diversos setores e Portes aqui né do
do uso do produto
eh o recebedor ali né então o problema
que pro recebedor ele aumenta a
previsibilidade dos valores a receber né
então o recebedor ele tem essa
previsibilidade mais clara ao mesmo
tempo o ele possibilita recebimentos sem
a necessidade de convênio entre
concessionárias e bancos então o
recebedor ele tem essa flexibilidade ali
sem ess essa algumas dessas amarrações
tá pro pagador ali tem uma maior
facilidade
eh e conveniência e praticidade na
utilização dos serviços pro pagador como
um todo quem que deve oferecer esse
produto aqui no nosso contexto né então
detentores e iniciadores né então a
oferta pelo iniciador ela é opcional né
só que pros detentores ali que prestam
serviço para clientes PF a a oferta ela
é obrigatória enquanto pro público
PJ a oferta ela não é obrigatória né se
o detentor eh tiver só aquele público de
atendimento E aí para ele poder eh pedir
ali a a não participação ele deve fazer
o opt out junto ao arranjo PX pedindo a
a a não participação aqui em si né então
e aí dando só mais um pouco mais de de
clareza em regras Gerais a conta
recebedora
aqui desculpa aqui que o o chat tá
pipocando e atrapalha aqui a min a minha
visão a conta recebedora ela deve ser
Obrigatoriamente uma conta PJ e a conta
pagadora ela pode ser tanto PF quanto
PJ acho que é isso aqui Yago se você
puder
seguir boa eh a gente
eh nós aqui da da estrutura assistimos
muito ali a eh todo o fórum pix eh o
circuito pix que o banco central
apresentou ali recentemente a gente
entendeu com com bastante valor ali
trazer mais ou menos a visão que foi
apresentada e tentar separar aqui
durante os fluxos aqui fluxos da jornada
de autorização o que acontece dentro da
trilha Open finance e quais são os os
fluxos de autorização que acontecem hoje
que são existentes e divulgados ali pelo
regulador na trilha pix né então o o
objetivo aqui é falar sobre um fluxo de
criação de consentimento sem o pagamento
de uma adesão o segundo fluxo aqui é
falar sobre o pagamento imediato da
Adesão e o terceiro é o com pagamento
agendado né então acho que esse é o
nosso propósito aqui nos próximos slides
pode seguir Iago
pois bem eh Seguindo aqui né tentando
dar um pouco mais de clareza para vocês
aqui turma isso aqui é um um um não vou
dizer que é um diagrama de sequência mas
é um é uma visão alto nível de como
seria as etapas aqui dentro do do Open
finance que a gente eh desenhou aqui do
produto né então o a primeira etapa aqui
o pagador acessa ao ambiente do
recebedor realiza a contratação de um
produto e serviço e escolhe como meio de
pagamento pix automático né então o o o
o ali as informações dos seus dados como
conta e os parâmetros dos limites da
transação são repassadas ali pelo
pagador ao receber
a segunda etapa o app do recebedor ele
tem uma integração ali com o itp né E
esses dados eles são
eh integração com itp ele notifica sobre
a contratação e os serviços e os
parâmetros a serem utilizados Então
existe toda uma integração ali desses
dois agentes que são repassados do
recebedor pro itp a etapa três ali né o
itp ele aciona o PSP do pagador através
das apis do Open finance né E cria um
consentimento pro pagamento recorrente
indicando ali os parâmetros do pagamento
do do recebedor nada mais é do que o
fluxo ali iniciando o fluxo fap que hoje
existe dentro do ecossistema e aí só um
um pequeno parêntese não é objeto aqui
dessa desse workshop entrar nas etapas
do fluxo fap como um todo né mas sim
trazer abstração do fluxo ocorrendo e
dando a clareza do do que é importante
aqui para vocês como eh telespectadores
aqui em relação à
informação ali aí entramos na etapa
quatro né onde o o o itp inicia o fluxo
fap para que o pagador possa provar o
consentimento do pagamento recorrente E
aí na etapa CCO o o usuário ele é
redirecionado pro pro ambiente ali da
detentora para poder fazer todo o
processo de autenticação aprovação e
redirecionamento pro pro recebedor Barra
itp para seguir no fluxo ali uma vez que
isso aconte desce o caminho feliz o o
itp notifica o recebedor e o mesmo
notifica o usuário pagador sobre o
sucesso da Adesão então aqui é uma uma
explicação em Alto Nível sobre todo o
fluxo da Adesão aqui do Pixel automático
dentro da jornada que a gente construiu
aqui dentro do nosso fluxo pode seguir
aqui pro próximo slide tá
Iago turma eh a diferença da Etapa um
para etapa dois elas vão se dar através
do dos itens 6 7 8 tá então tanto a
etapa 1 A5 ela é Idêntica ao outro fluxo
aonde o usuário escolhe e os dados
escolhe o produto e serviço que ele vai
contratar o o recebedor passa essa
informação pro itp o itp inicia o fluxo
ali dentro do das APS do Open finance A
diferença é que na etapa seis o itp ele
cria uma solicitação de pagamento
imediata acionando a nossa api aqui que
é a post recing payment referente à
adesão do serviço que foi eh com
contratado pré-estabelecido do junto do
recebedor com o usuário
pagador uma vez ali isso eh o iniciador
tendo feito essa chamada o PSP do
pagador ele recebe a solicitação ele
valida as informações ali recebidas e
confirma a requisição ao iniciador sobre
a liquidação do pagamento no no spi E aí
de novo não é objeto dessa apresentação
trazer detalhes do que acontece na na na
estrutura do do arranjo ali do do do pix
em cim mas sim trazer as etapas do nosso
fluxo aqui do Open
finance com base nessas informações ali
né uma vez que o o detentor faz a
liquidação do pagamento no spi ele
retorna essa informação ali pro pro itp
o itp ele valida ali todas as
informações do pagamento recebida ele
consulta se o status da transação ela
foi alterado e aí o status aqui que a
gente tá fazendo a menção são os status
da nossa máquina de pagamento né se ele
foi pro status de sucesso onde um
pagamento foi realizado que é o acsc ou
se ele foi pra rejected E aí Dependendo
de qual caminho seguir aqui e aí de novo
objeto é sempre falar do caminho feliz
ele notifica o recebedor do resultado e
o recebedor notifica o usuário pagador
sobre o sucesso no pagamento imediato
ali dentro do fluxo tá
eh pode seguir aqui pro próximo slide
ag por favor
E aí por fim turma aqui também eh a
diferença ela acaba ocorrendo eh entre
os steps 6 7 e 8 né só que a diferença
aqui a jornada ela continua sendo a
mesma só que a diferença ela acaba sendo
que na etapa seis ali o itp ele consulta
o eh se um consentimento ele foi
transitado ali na nossa máquina do de
consentimento na nossa máquina de estado
do consentimento para autor
E cria uma solicitação de agendamento
com a mesma data
eh Da solicitação enviada como primeiro
pagamento Então essa é a diferença que
eh do fluxo do da da do pagamento
imediato pro pagamento agendado Desculpa
quem tá falando oi wend é a Vanessa
desculpa te interromper você tá
compartilhando Será que é só para mim
que não tá aparecendo Ah o que que você
pode fazer van tá aparecendo aqui
Vanessa Aqui também tá na obrigado gente
normal aqui entre sa vanissa que pode
ser um problema no teams ali em relação
a bufferização tá tá ótimo obrigada
Desculpa aí o que
isso perfeito e aí Seguindo aqui né
então o itp ele consulta o status do
consentimento dentro da máquina Nossa
aqui de de consentimento aqui né Eh para
ver se o pagamento se o estado o estado
do consentimento ele tá como authorized
né
E aí tando como authorized ele ele cria
a solicitação do agendamento com a mesma
data da solicitação enviada como
primeiro pagamento a etapa Sete ali né
o PSP do pagador ele valida as
informações recebidas confirma a
requisição ao iniciador e retorna O
sucesso do agendamento Então ele recebe
ali todas as informações repassadas pelo
detentor valida isso e confirma ali e aí
a etapa oito né o itp ele valida a
confirmação do agendamento pelo PSP do
pagador ele consulta dentro da nossas da
da AP do Open finance o recurso payment
ID onde tem todas as informações
atreladas ao pagamento para saber em
qual status o pagamento ele foi
transitado se ele tá em Schedule né que
tá agendado se ele foi rejeitado ali por
algum motivo aparente tando tudo certo
ali indo pelo caminho feliz pelo caminho
do do Schedule O O itp ele notifica o
recebedor o recebedor eh recebe essas
informações e Repassa todo o sucesso
dessa transação pro usuário pagador tá
eh esse é o fluxo como um todo aqui
dentro das Jornadas da da do do Open
finance que a gente desenhou
eh acho que só para poder fechar aqui
mais um ponto turma dentro desses fluxos
aqui eu acho que é válido a gente deixar
claro que pagamentos criados tanto com
uma modalidade de e agendado ou ou
imediato e eles mais a parte
negocial Opa desculpa acho que alguém
falou não sei se vazou o áudio eh
perfeito acho que só vazou um áudio aqui
eh os pagamentos agendados imediatos
eles consomem ali dos limites de do pix
normal de um pagamento imediato ali
então não existe uma uma uma consumação
dos limites eh do pix automático mas sim
do pix eh imediato
da
tro né Fala aí fala aí Zé isso da o
consumo do limite aí pessoal conforme
previsto no manual de fluxos do arranjo
também tá
eh o Pag o pix imediato ou agendado ele
segue a trilha de efetivação do pix
normal tá e não do do pix
automático então eu tô vendo ali a
pergunta sobre a retent ativa eh de fato
tá a as R Tentativas aplicadas em cima
do primeiro pagamento são apenas as
Tentativas aplicadas em cima dos
pagamentos agendados tá então o
pagamento agendado ele tem as janelas de
tentativa de liquidação e tem a janela
de renta tá pelo detentor então São
esses os únicos a única renta prevista
pro pagamento agendado da Adesão boa Zé
bom ponto
Obrigado pode seguir
[Música]
aí aqui turma a gente
entra algumas que a gente construiu
dentro do nosso do nosso arcabo sobre as
possibilidades de edição e as suas
condições ali que cada participante pode
ter cada ator pode ter dentro do
ecossistema então a gente traz aqui né
uma visão do que é possível editar
dentro do ambiente do detentor
eh O que é possível né então o valor
máximo permitido da cobrança a a
utilização do cheque especiais são dois
parâmetros que hoje já existem na trilha
p que permaneceram aqui dentro do Open
finance quem edita é sempre usuário aqui
dentro do nossa trilha né E aí a gente
tem traz também uma outra condição que o
usuário ele precisa sempre estar
presente para poder executar essa
modificação E aí qual o tipo de
modificação que pode ocorrer né então Eh
no uso ali do na questão do valor máximo
permitido para cobrança então o usuário
ele pode aumentar o valor da da da
cobrança reduzir o valor valor ou até
mesmo definir um valor ali no qual ele
não tenha aplicado
eh na etapa do consentimento mas sempre
respeitando o valor mínimo definido pelo
pelo usuário recebedor então um caso de
uso aqui uma aplicação uma
aplicabilidade bem simples aqui é dizer
assim né então
Eh eu vou fazer a contratação de um
serviço de streaming eu sei que o valor
do serviço de streaming ali que o
usuário que o usuário recebedor define é
sempre de r$ 50
eh e eu como o valor máximo por
transação quero definir que o o
recebedor caso exista alguma flutuação
ali no pagamento então eu quero
adicionar na minha cesta de serviço mais
algum algum outro pacote do serviço de
streaming posso definir que até mais r$
2 eu eu aceito ser cobrado Então essa é
a trava aqui do valor máximo eu posso
também dizer que eu posso reduzir esse
valor ali mas sempre respeitando o piso
da cobrança que o recebedor coloca ou
definir um valor em si a mesma coisa
vale paraa questão do uso do cheque
especial então o uso do cheque especial
Ele sempre vai vir habilitado como
default então eu como usuário eu posso
definir se eu quero ou não ter essa
possibilidade de edição ali ó de edição
não de utilização do cheque
especial pode seguir alí por
favor aqui turma a gente tem um o o que
é permitido também dentro da trilha pix
eu só vou seguir com essa última
explicação E aí eu passo a palavra tá
não sei se acho que a Ana que levantou a
mão aqui
eh O que que é permitido dentro da
trilha pix aqui eh dentro da trilha pix
desculpa dentro do do do ambiente do
iniciador seguir aqui com as edições
aqui né Então quais são os parâmetros
que podem ser eh modificados eh a razão
social ali né o creditor names a data de
inspiração de um
consentimento e o valor máximo eh no
qual eu havia comentado anteriormente
então aqui a gente também tem algumas
regras e os momentos que isso podem
acontecer também então quando a gente
fala de
eh o creditor names quem que pode fazer
isso só o recebedor o usuário precisa
est presente não então um exemplo aqui
então tem uma operadora de telefonia que
presta serviço para mim antes ela tinha
o nome a razão social dela como Embratel
ela modificou a sua razão social para
Claro é um caso de uso que isso aqui
pode ser feito só pelo usuário recebedor
sem a necessidade do pagador tá ali
dentro do fluxo né Eh a inspiração do
consentimento aqui né então o recebedor
ele pode fazer isso entretanto o usuário
ele precisa est presente aqui dentro
também então um um caso de uso aqui
então um
determinado serviço que o recebedor
presta uma venda de um curso né que é o
mais comum esse esse recebedor ele
coloca ali como prazo eh de de de
vigência para você utilizar aquele curso
é de 12 meses só que por algum motivo
Ele entende que na negociação que ele
fez com o usuário pagador ele tá dando
ali uma condição melhor pro pro usuário
pagador e ele quer aumentar essa
possibilidade ao invés de você consumir
só por 12 meses você faz uma negociação
comigo por fora e eu te dou aqui mais a
possibilidade de você conseguir ou por
fora ou por dentro Óbvio aqui dentro do
nosso fluxo de consumir mais o serviço
por 18 meses ou simplesmente reduzir o
prazo ali Inicial isso tem que sempre
estar acordado entre ambas as partes né
então ao invés de 12 meses eu preciso
fazer uma adequação aqui dentro do nosso
do meu curso e ao invés de ser 12 passa
a ser H 10 meses ali ou simplesmente eu
quero eu como usuário recebedor eu quero
colocar um prazo indeterminado contr
contrar compro compro o meu curso aqui
nesse momento black friday e eu te dou
acesso vitalício E aí você pode fazer
isso daí da melhor forma possível tá E
aí de novo o usuário aqui no ambiente do
iniciador ele pode
eh mudar o valor máximo permitido da
cobrança aí eu acho que eu não vou
repetir algo que eu já falei
anteriormente só que o usuário ele pode
fazer essa edição no iniciador e
eh o usuário ele precisa est presente
também para poder fazer essa adequação n
é ambíguo aqui eu acho que só algumas
considerações aqui para deixar bem claro
esse slide aqui né em momento de edição
o envio de sinais de risco eles são
obrigatórios aqui para pra gente poder
aumentar a aderência da aplicabilidade
do serviço então é necessário que seja
enviado no ambiente da iniciadora os
sinais de riscos ali pro detentor para
ele conter ali as informações sobre as
modificações quem tá alterando em um
momento tem tem toda uma regra dentro da
nossa especificação que contém ali todas
o o o que é parametrizado e passado aqui
entre as partes né E aí por fim só para
F de registro aqui dentro da nossa
documentação Foi algo que a gente teve
aqui bem forte algumas discussões dentro
do próprio GT o fato do de ter ali
algumas diferenças da possibilidade de
edição no ambiente do detentor e edição
no ambiente do iniciador mas a gente
conseguiu ficar isso aqui a regra lá
hoje ela é Clara e aí o fato do cliente
poder parametrizar as informações na itp
na trilha do Open Fes não configura a
não aderência ao regramento vigente pois
são atores e processos diferente e é
natural que essa jornada ali no Pixel
automático tem ali algumas questões de
acomodações que elas precisam ocorrer
dentro do nosso
fluxo acho que é isso daqui Ana
é perfeito tá Obrigada pela explicação
porque essa última parte que você falou
vai exatamente de encontro aqui com com
as dúvidas do que nós temos e do que
exatamente tá desenhado no guia deux
hoje tá e eu acho que até para não
causar tanto aqui em específico a gente
pode estar marcando uma específica ali
pedir para o secretariado de GT serviços
e o x pra gente fazer essas pequenas
alterações necessárias porque hoje Se
for olhar o Gu X Ele não está definido
desta forma tá E aí só a minha dúvida
anterior que era referente à etapa ali
da do ambiente né no caso do detentor do
cliente poder alterar uma dúvida que vai
coincidir aqui com dupic automático mas
também com transferências inteligente
então como se trata da mesm ambas as
apis né vamos assim dizer de pagamentos
automáticos a gente tá falando que o
cliente ele pode configurar se ele quer
ou não utilizar o cheque especial e isso
vai ficar é responsável o cliente pode
fazer isso no momento do consentimento
aí eu se for no momento do consentimento
precisamos criar esse requisito para o x
também ou somente ali na tela de na área
de gestão E aí do pix automático a área
de gestão ela pode ser tanto do Open F
quanto do do produto pix automático mas
para transferências inteligentes isso
hoje não existe certo é é uma dúvida se
a gente vai poder ou não depois hoje não
bom ó eu vou vou passar aqui e aí acho
que como a gente abriu margem aqui para
essa pergunta Talvez para não tumultuar
os próximos apresentadores eu V Vamos
responder essa primeira aqui eu acho que
o restante a gente tenta consolidar e
abre no final ali da da Apresentação mas
eh Ana hoje dentro da documentação o a
utilização do uso do cheque especial
para transferências inteligente também
ela foi parametrizada dentro do da das
especificações é algo que precisa ou
deve ser refle tido dentro do da
experiência em si ali do guia deux acho
que era isso aí bresler se você quiser
tá ótimo perfeito end Eh boa parte
dessas dúvidas a gente vai abordar
também na São de de o x E aí Ana se você
quiser deixar elas no no chat eu
agradeço também que daí a gente vai vai
Relembrando elas no momento que que a
gente for passar e E aí fica mais mais
fácil da gente dar o segmento E e trazer
incorporar as contas de vocês também tá
bom eh eu tô atualmente eu não tenho
acesso a chat mas eu mando um e-mail ali
direto tá para você e a gente discute em
x obrigada a ideia mesmo era não não não
tumultuar tá é só pensando o que tem do
guia hoje já relacionando com vocês
obrigada E desculpa interrupção que é
isso não mas eu acho que é válido as
perguntas só que como o fluxo aqui né da
apresentação ele ele tá bem denso e tem
muita coisa eu acho que pode ser que
muitas das respostas já possam ser
respondidas da minha parte é isso aqui
na visão do produto tá turma eu vou
passar a bola pro pro Zé ele vai dizer
ali algumas questões das regras e entrar
na parte técnica da nossa documentação
Zé tá contigo meu
amigo beleza
obrigado Vocês conseguem me ouvir
pessoal
certinho
sim perfeito
eh primeiro Boa tarde a todos né Eu sou
José trabalho ali na estrutura de
serviços né junto do serviços Squad jsr
e etc
eh bom eu vou entrar aqui um pouco nos
detalhes de como vão funcionar as
tentativas intra dia tá eh não só as
intr dias como as em dias subsequentes
também e falar um pouco dos detalhes
sobre as quantidades de R tentativas e
como contabilizar se foi uma tentativa
ou não além disso a gente também vai
falar no final se um um texto um pouco
mais flet sobre as alterações que
incorreram ali tanto em consentimentos
quanto em pagamentos e assim não voltar
todas ali porque seriam muitas então a
gente elencou algumas principais que
assim na nossa opinião pelo menos teria
um impacto maior no desenvolvimento e
elencou ali eh as demais vocês podem
encontrar no Change log que vai tá a
gente inclusive tá lançando agora um
release Notes também além do Change log
tá então A ideia é que a gente tem ali
uma motivação das mudanças Então se
vocês puderem conferir dar feedback
depois também no R Notes a gente
agradece bastante tá
eh falando aqui agora inicialmente das
tentativas intradia tá a gente para
poder facilitar o entendimento a gente
achou que era melhor trazer um
cenário onde a gente já tem um
consentimento criado autorizado pelo
cliente tá e a gente tem a itp passando
a fazer cobranças subsequentes nesse
consentimento tá aqui a gente não tá
falando do primeiro pagamento a gente tá
falando das recorrências tá Associados a
uma série então Eh o cenário que a gente
tem aqui é eh dado que essa janela do
tempo né a gente tem a o dia 16 17 até o
dia 25 eh a gente tá considerando que o
a data de referência o effen start date
time ele é um campo novo tá que entrou
na beta 2 eu vou entrar mais no detalhe
nele mais lá na frente mas esse campo
ele hoje vai trazer a data fixa da
primeira liquidação prevista para esse
consentimento tá tanto para só da
primeira porque em momento de
autorização acho que todo mundo já tá
ciente do guia de X do arranjo a gente
tem de que mostrar a data prevista paraa
primeira liquidação a ocorrer Então esse
campo vai ser o responsável por trazer
isso nas nossas apis né Eh então
lembre-se não é a data que eu vou
agendar o primeiro pagamento para ele
ser liquidado depois é a data que aquele
pagamento vai ser liquidado tá então
observem a gente tá mencionando aqui que
a data que esse pagamento vai ser
liquidado que foi informado ele é no dia
18 para permitir que eu liquide no dia
18 e seguindo as regras de 10 a 2 dias
antes essa Esse agendamento deve ter
ocorrido no dia 16 tá então basicamente
a gente enviou ali o que tá escrito no
cenário né data de envio 16 dois da 10
dias antes da liquidação eu mandei um um
pagamento no dia 16 né então ele entra
ali para ser liquidado por exemplo no
dia 18 tá tudo certinho eh a primeira
janela de liquidação para esse pagamento
agendado para dia 18 ele ocorre segundo
a regulação pelo detentor de meia-noite
às 8 da manhã beleza existem caso
existem casos a onde esse pagamento não
pode ser liquidado por diversos motivos
eh alguns desses motivos exigem eh em
todos esses casos vai ocorrer uma
segunda janela de retent tativa tá de de
tentativa para esse pagamento que falhou
é importante lembrar aqui que ela tá
prevista das 18 a 21 horas porém
dependendo do motivo que falhou o
pagamento na primeira janela pode ser
necessário o reenvio ou não do endend ID
para aquela liquidação poder ser
processada novamente pelo detentor na
segunda janela tá então o que que eu tô
dizendo eu tô dizendo que de acordo com
o erro retornado na primeira janela de
liquidação pode ser necessário que o itp
envie um novo ID porque aquele ID Origin
original da tentativa que falhou ele foi
enviado pra frente pela detentora ele
saiu da detentora foi pro spi foi pro
PSP do recebedor então a gente entende
que aquele ele foi queimado ele não pode
mais ser utilizado tá então por isso a
gente tem casos de erros né que eu vou
entrar mais no detalhe de quais são que
exige um novo end ID o caso os erros que
não exijam o novo end ID eles também não
dependem de um estímulo da iniciadora
pro pro detentor poder tentar novamente
na janela das 18 21 tá então é important
a gente ressaltar aqui que se for um dos
erros previstos para como necessário o
envio de novo an o detentor só deve
retentar depois de receber esse novo an
sen não ele deve retentar por conta
própria a na segunda janela
eh bom falando agora das tentativas de
intradia com nid né sendo específico
nessa parte
eh como já mencionei ele pode ser
necessário o envio de novo ened pelo itp
E esse novo envio de ened vai gerar um
novo pagamento tá e a data de pagamento
esse vai ser digamos o único cenário do
Open finance que você vai poder ter um
pagamento agendado pro mesmo dia porque
a gente tem o horário ali de meio-dia né
que é o horário máximo para o itp poder
fazer esse reenvio e entre o meio-dia e
a data e o horário da liquidação a gente
entende que esse pagamento ele pode
ficar como agendado ou ele pode ficar em
um estado assim a gente entende que não
tem muita muita restrição Nessa versão
atual ainda a gente ainda vai debater um
pouco sobre isso em qual estado que esse
pagamento deve ficar e etc mas Nessa
versão atual a gente entende que ele
deveria ficar em agendado tá então uma
vez que o o itp faz essa nova
solicitação até meio-dia o detentor
agenda novamente ali e na janela das 18
a gente 21 ele tenta novamente enviar
paraa liquidação esse novo
Eh os dados do pagamento né eles vão ser
os mesmos ali a gente teve um typo Zinho
ali com exceto a data mas não tá a data
também é a mesma data porque a gente tá
falando da tentativa entrad aqui tá
então a gente teve a tentativa original
que tava previsto pro dia 18 e ela
ocorreu ali a primeira janela de
meia-noite às 8 falhou então a segunda
tentativa ainda é a mesma data tá a
segunda tentativa para esse mesmo
pagamento então ainda é AES mesma data
Então o que vai mudar de fato nele é o
end ID E além disso a gente vai ter a
presença do original recur payment ID
esse campo ele representa que o
pagamento original que originou essa
nova tentativa falhou e o itp para ficar
claro pro detentor na hora da tentativa
de liquidação que essa é de fato uma
nova tentativa para um pagamento que
falhou Independente de ser int dia ou em
dia subsequente vai est preenchido o no
recing payment é dita para ter essa
distinção Clara de quando é uma nova
tentativa de quando é uma pagamento
original
eh os e eu falei que entrar mais nos
detalhes dos erros né os erros que a
gente preveu que exigem um o envio de um
novo infringed pelo itp são o não
informado né porque o não informado a
gente não sabe exatamente se o pagamento
saiu ou se não saiu então pelo sim pelo
não a gente exige o reenvio tá e o
detentor tem que acatar e eh E além
disso todos os outros motivos a gente
entende que são motivos que já eh que o
o pagamento já foi enviado paraa frente
pelo detentor tá então por ele já ter
sido enviado paraa frente para tentar
ser liquidado Ou aquele já foi queimado
no spi e não tem mais como você utilizar
tá eu acho que é é isso Iago você pode
ir pra próxima por
favor falando agora das Tentativas em
dias seguintes pessoal a a que a gente
veio tratando como extra dia tá Tá mas
eu acho que o termo mais correto seria
em dias seguinte e a gente ainda tem
aquele mesmo cenário que eu que Eu
mencionei antes né E só que aqui a gente
tá indo agora no caminho de que esse
pagamento do dia 18 não não ocorreu de
fato não ocorreu tá então independente
do itp ter informado o novo infed a
segunda Tentativa do detentor não não
conseguiu realizar a liquidação desse
pagamento
eh essa essa tentativa fora do dia ela
só pode ocorrer
caso o usuário tenha aceito durante a
criação do consentimento que houvessem
novas tentativas estadia para aquele
pagamento Tá então a gente tem ali um
campo dentro da api que ele é chamado de
eas Ret accepted o eas retry accepted é
uma marcação que o usuário vai ter que
fazer durante a criação e autorização do
consentimento para indicar tanto paraa
itp quanto pro detentor se ele permite
que o recebedor Gere novas Tentativas em
dias subsequentes né ele tem até 7 dias
e ele tem até três tentativas novas para
fazer dentro desses 7 dias tá E os S
dias são contados a partir da data de
falha do pagamento original então eu ten
a primeiro aqui no nosso caso era o dia
18 né então o dia 18 ele é o dia que eu
declarei como o dia de liquidação do
pagamento para aquele ciclo eh se eu
chego no dia 18 pagamento daquele ciclo
Falhou Eu posso dentro de 7 dias a
partir do dia 18 fazer até três
tentativas tá
eh essas tentativas elas vão ter todos
os dados do pagamento igual tá cálculo
de juros deve ser feito na cobrança
subsequente tá e acordado com o o
pagador tá então ele vai ter que ter o
mesmo valor que tinha na cobrança
original e as informações de recebedor
vão ter que ser o mesmo tudo vai ter que
ser o mesmo com exceção da data que
agora você vai ter a nova data do
pagamento né que a gente tá programando
ali no nosso cenário pro dia 22 por
exemplo a gente vai ter o end TR de novo
né e semelhante ao que a gente tem ali
na quando o itp faz a nova tentativa
entr ele também vai fornecer o original
recur payment ID aqui tá então o
detentor imposto desse original recur
payment ID a pode ver que aquele aquela
tentativa original ocorreu no dia 18 vê
se ainda tá dentro do prazo de 7 dias
para poder aceitar uma nova requisição E
além disso a gente eu acho que a gente
deu avançar é importante mencionar aqui
que todas essas as regras de validação
de novas tentativas elas estão abaixo
desse desse rejection reason tá esse
rejection reason tá bem abaixo delas que
é o detalhe tentativa inválido então
caso o itp durante a execução de novas
tentativas informe Algo Além disso que
tá mapeado aqui para ser informado o
detentor deve rejeitar a solicitação de
Nova tentativa tá com aquele motivo ali
dizendo que a algum detalhe na nova
tentativa que ele tá executando não tá
coerente com a tentativa original
eh Além disso
ele eu já mencionei ele tem os S dias né
contados ali para poder fazer essa nova
tentativa né caso ele Tente fazer uma
tentativa fora desse prazo de 7 dias eh
a gente tem também um motivo de rejeição
novo que é o fora prazo permitido tá
então o pagamento deve ser rejeitado
pelo detentor a gente não eu Salvo
engano a gente não definiu se é síncrono
ou assíncrono tá pode ser retornado em
qualquer em qualquer um dos meios ali
pelo detentor
eh e a questão de até quando ele pode
fazer um agendamento né para quando que
é Esse agendamento quando que eu faço e
para quando que eu faço então ele você a
data do agendamento ela é sempre até as
23:59 do dia imediatamente posterior ao
dia que você quer liquidar tá então se
você tem o a data de liquidação do nosso
cenário aqui proposta dia 22 o pedido de
agendamento para essa nova liquidação
tem que ser feito no dia 21 eh
[Música]
eu entendo que é isso
tá osé tem uma pergunta se puder voltar
ali naquela outra na outra tela aquele
is Ret quem define é o pagador ou o
recebedor é o pagador Rui
o tô olhando aqui na especificação né
talvez a gente possa discutir depois mas
aqui diz indica que é permitido pelo
cliente recebedor fazer R tentativa mas
isso tá vindo na criação do pagamento tá
certo perfeito assim é o usuário pagador
que indica ao recebedor se ele pode ou
não fazer
tá é aquilo ali é a vontade do pagador
em permitir ou não ao recebedor a
execução eu acho que a gente pode
trabalhar na melhoria da descrição ali
tá mas não é o pagador que define não
perdão não é o recebedor que define é o
pagador tá
beleza agora pessoal falando pouco da
quantidade possível de novas tentativas
né A gente contando né assim a primeira
tentativa original que falhou ela pode
sofrer uma renta intradia ali né então
já seriam duas cada nova tentativa extr
diia também passa pelo ciclo de R
tentativa intradia então além da
original que falhou poder ter mais uma
tentativa a gente ainda tem mais três
tentativas extradas que podem também
sofrer uma tentativa intradia em caso de
queima do end dita então ao todo oito
tentativas podem ser realizadas agora
quando que o detentor vai contar se
houve ou não uma tentativa ali porque
tem alguns casos de erro que a gente
entende que o erro em si não não tem
como contabilizar como uma tentativa
porque teve algum problema na na
requisição em si por exemplo um Bad
request a gente entende que não faz
sentido contar como uma tentativa porque
não foi nem aceito para ser processado
então assim alguns erros eles não serão
contabilizados como uma tentativa tá
permitindo que o itp não seja penalizado
com algum erro operacional ali ou alguma
falha de infraestrutura interna durante
a criação dos pagamentos sabe então para
permitir que ele não seja onerado caso
isso aconteça e ele possa realizar todas
as tentativas que ele tem direito a
gente definiu uma tabela bem específica
a gente optou por não trazer aqui porque
a apresentação ela tem um um período de
tempo curto né mas ela tá disponível ali
na nossa documentação na área do
desenvolvedor de tentativas intradia e
extrad tá então ali a gente tem uma
tabela que indica quando que é
contabilizada uma tentativa quando que é
exigido o o envio do ent id e eh E além
disso a gente tem um outro são três
colunas que tem ali tá eu não não lembro
aqui de cabeça mas a que importa pra
gente nesse caso aqui é a questão da
contabilização Então você tem ali uma
lista com todos os rejection reason
previstos na api né aplicáveis pro
produto pix automático e quais deles
contabilizam ou não como uma uma
tentativa tá para todo mundo tá
eh contando da mesma forma dos dois
lados tá para você não como o detentor
não achar que foram realizadas sete por
exemplo ou oito enquanto que o iniciador
acha que foram realizadas cinco ou seis
tá então para todo mundo tá ciente de
quantas foram realizadas e quantas foram
feitas
eh a gente optou por deixar bem definido
isso um escopo bem bem claro Tá vendo
Rosé só só complementando ali as colunas
são eh eh contabiliza a tentativa
permite nova tentativa ent diia e exige
o envio de end Trend ID
perfeito Obrigado V então a tabela além
de contemplar isso esse essa informação
que eu tô mencionando agora ela também
contempla
a as informações que Eu mencionei
anteriormente né que são quais erros
preveem o envio do
endd e quais erros eu já esqueci de novo
mas espero que vocês não tenham
esquecido S uma perguntinha rápida Nesse
contexto desculpa interromper eu sei que
mais pro final mas se vai ser cobrado
juros ou não também tá previsto né essa
documentação o juros só vai poder ser
cobrado na no ciclo posterior tá não eu
sei mesmo sendo no ciclo posterior Mas
dependendo do Tá previsto Que Tem
situações que não se cobraria juros
porque algum erro de infra alguma coisa
assim posso não a gente a gente não tem
isso previsto hoje tá Alexandre a
questão da cobrança de juros ela é 100%
a cargo do recebedor com o pagador tá a
a gente aqui inclusive em questões que
podem ser já juros ou coisa assim a
gente indica que seja criado
consentimento com valor variável tá
então é é bem importante ter essa
descrição na hora de criar o
consentimento ai se o recebedor vai
permitir que tenha retent ativas E caso
essas retent ativas entre um período não
seja executado vai haver cobrança de
juro tudo isso tem que ser muito bem
acordado entre o pagador e o recebedor
no momento da contratação do serviço tá
a gente aqui não tem uma Flag indicando
se permite cobrança de juros ou não tá a
gente tem um campo de cobrança de valor
variáveis e a cobrança variável vai
depender do acordo do recebedor com o
pagador o pagador Eh caso ele não se
sinta confortável com o valor que chegar
ali em caso de encargos e juros etc ele
pode cancelar porque toda cobrança chega
de 2 a 10 dias antes então ele pode
cancelar entrar em contato com o
recebedor solicitar o cálculo novamente
do juros ver se tá tudo certinho e o
recebedor envia a liquidação para ele tá
inclusive Tá previsto aqui que o o
enquanto o novo ciclo não iniciar é
possível chegar a cobrança do ciclo
anterior ainda tá inclusive é por isso
que a gente adicionou também um campo
novo chamado payment reference no
pagamento que a gente vai entrar no
detalhe mais à
frente
é o que eu quis dizer que a postergação
da data de pagamento também eh pode ser
aceita
tá entendi eh Além disso De nada além
disso a gente também adicionou ali como
Último Ponto desse slide né a gente
adicionou também um paran novo no
endpoint de get porque a gente entende
que com essa grande quantidade de
pagamentos que podem ser criados eh
talvez fique confuso durante a consulta
eh de saber qual pagamento que foi
originado a partir de original que
falhou como que eu faço para consultar
só só os pagamentos de um ciclo
específico por exemplo todas as
tentativas para um ciclo específico
eh apesar da gente ter um campo chamado
payment reference hoje a gente achou que
mais seguro seria amarrar pelo pelo
pagamento original que falhou né como
vocês viram todas as tentativas elas vão
todas as novas tentativas originadas a
partir de uma tentativa original que
falhou que geraram um novo pagamento ali
pelo itp elas vão receber o original
recur payment ID como parâmetro no bor
tá eh pensando nisso sabendo que esse
campo vai est presente em todas as novas
tentativas a gente adicionou esse campo
como um query parando o nosso end Point
de get amplo ali que seria o get o de
consulta por consente id e datas né a
gente tem janelas de início e fim e
consente ID então além de você poder
filtrar por consentimento que é
obrigatório e janelas de início e fim
que são opcionais você agora vai poder
também passar o original recur payment
id e ele vai trazer dentro daquele
consentimento todas as tentativas que
estão associadas à aquele ciclo tá então
é mais uma adição para facilitar a
operação do dia a dia pode passar aí
água por favor
agora é a parte interessante pessoal
aqui é onde a gente tem as alterações
digamos assim mais flat né que não tem
tanta digamos assim a regra de negócio
ela é menos menos complicada pra gente
precisar ter um um um slide apresentando
né então vou passar aqui discorrendo com
vocês um a um n o primeiro foi alteração
no local do campo start date time né ele
foi movido para dentro da estrutura do
sweeping primeiro porque hoje a maneira
de você referenciar a data de início do
consentimento ela é diferente do Pixel
automático e do suep então a data de
início do swiping ela se mantém com a
mesma funcionalidade tá só que como a
gente tem essa diferença entre um e
outro para evitar confusões semânticas
dentro da do significado a gente achou
melhor mover essa estrutura de start
date time para dentro do objeto do sweep
Além disso para poder representar essa
data de início conforme eu já mencionei
também lá na na linha do tempo né que a
gente mencionou das tentativas a gente
tem o refer start date time Esse vai ser
o campo que vai trazer hoje a data flat
da expectativa da primeira liquidação
daquela daquele ciclo de recorrências tá
E também serve pro detentor poder
calcular os novos ciclos a partir de
quando receber e
etc perdão além disso a gente também
teve a remoção do Campo monf né quem
veio acompanhando a evolução da pi entre
a
1.0 e a a Beta 1 da 2.0 viu que a gente
removeu ali o Day of Week o Day of month
eh porém a gente ainda tava tendo
discussões de como seria essa essa data
fled como seria né ofertada Essa data de
início do consentimento então uma vez
que a gente bateu o martelo que seria o
ref time a gente removeu o monf porque
ele não tem mais valor semântico pra
gente eh Além disso ele a gente também
alterou o nome do campo P né passamos a
chamar ele de interval porque a gente
entende que perod talvez gerasse uma
confusão porque perod não significa
periodicidade significa período e
período e periodicidade intervalo são
coisas diferentes então para dar uma uma
melhorada na no significado a gente
mudou o nome Além disso aqui é bem
importante tá esse é um ponto que eu
peço atenção de todos a falha no
pagamento declarado no objeto lá dentro
do first payment não invalida o
consentimento tá
então ou a falha Eh caso o pagamento
enviado dentro do first payment eh F né
que é o pagamento da Adesão que a gente
tá chamando aqui ou ele nem seja enviado
por algum problema no itp isso não deve
causar a a revogação do consentimento tá
a gente entende que existem outras
maneiras do recebedor ofertar esse
primeiro pagamento pro cliente não
necessariamente precisa ocorrer aqui no
nosso arranjo tá Ele Pode Ele Pode pagar
ele pode ofertar um um link de cartão de
crédito para ele pagar esse primeiro
pagamento Eh caso falhe aqui né por
algum motivo Ele Pode Ele tem outras
maneiras de recuperar esse primeiro
pagamento que não seja cancelando esse
consentimento aqui tá então a gente
entende que a comunicação do recebedor
com o pagador ela é essencial em todas
as etapas e essa é uma das etapas também
que é essencial a comunicação tá então
no caso do do primeiro pagamento falhar
e isso ser estritamente necessário pro
recebedor ele pode em comum acordo com
itp solicar a revogação do consentimento
autorizado tá então por exemplo um caso
de uso de um um serviço de um de um
player de vídeo por exemplo que ele
exige que você pague para poder começar
a usar ele com certeza ia ia optar por
rejeitar o consentimento ou revogar caso
o primeiro pagamento não funcione agora
por exemplo uma matrícula de uma escola
que você faz a matrícula bota por pix
automático primeiro pagamento não
funcionou você pode ir lá na escola por
exemplo pessoalmente mesmo e negociar né
para pagar aquele primeiro pagamento e
não perder a autorização não perder a
recorrência a escola poder continuar
mandando tá então fica a cargo dos dois
lados ali poder definir como que se vai
continuar se não vai n o recebedor é
sempre livre para cancelar assim como o
pagador também tá então
eh a gente entende que e essa é uma
diferença eu acho que outro ponto
importante de ressaltar disso é que é
uma diferença eh digamos assim táa do
arranjo né no arranjo se o primeiro
pagamento falhar ali então a recorrência
como um todo também não vai acontecer tá
enquanto que aqui não
eh falando agora da edição do
consentimento né que o ainda deu uma
pincelada ali de como funcionaria os
atores envolvidos e quem faz quando faz
e quem tá presente né para poder
permitir que tudo aquilo que ele falou
aconteça a gente teve que fazer algumas
alterações no endp de de edição não só
edição do consentimento né mas ele
também funciona para edição revogação e
rejeição
eh basicamente agora acho que a regra
mora aqui é que somente usuários com
plenos poderes em cima do consentimento
podem editar tá então se os usuários se
o usuário solicitando alteração se o
usuário logado no ambiente do itp
solicitando alteração não tem alçada
para realizar alteração sem precisar de
outros aprovadores ele não pode realizar
alteração Ele só pode realizar alteração
se essa alteração não depender da
aprovação de mais pessoas para permitir
a identificação desse usuário né que tá
logado no ambiente do itp foi adicionada
a estrutura de log US Business en né que
já uma são estruturas conhecidas aqui
pela pela convenção a gente usa em
praticamente
quos que a gente tem
esse cenário do usuário que não tem
permissão a gente colocou ali um erro
novo na especificação chamado permissão
insuficiente que representa justamente
isso o fato do usuário não ter permissão
para editar aquele consentimento sem ter
outros aprovadores passando por sem
passar por outros aprovadores né Eh como
o end mencionou ali com aquele quadro de
alerta o envio do sinais de risco para
edição agora é obrigatório tá porque a
gente entende que como é possível mexer
no valor máximo Então disponível eh faz
sentido ali pro detentor ter essa essa
segurança de poder ter algum sinag deiso
para poder aplicar ali dentro das
Ferramentas de segurança e e aceitar ou
não essa essa
alteração agora entra eu acho que foi
até uma pergunta aqui no chat né como é
que funciona para fazer alteração para
valores indeterminados né
Eh bom eu vou pedir que vocês se atentem
um pouquinho aqui que esse é é é um
pouco não usual tá a maneira de fazer eh
então basicamente a gente tem ali por
exemplo durante a criação do
consentimento o o usuário junto do
recebedor podem ter definido uma data de
inspiração e um valor máximo para aquela
transação né então considerando que
esses dois valores já existem hoje
quando você faz uma consulta ambos vão
retornar a na no payload certo Porém
para permitir a compreensão Clara do
detentor durante a edição que aquele
consentimento que já tem um valor
definido eh tanto paraa data de
inspiração quanto pro valor máximo
variável que vai poder ser trafegado eh
durante a edição do consentimento eh o
campo que o iniciador quiser mover para
Indefinido vai ser o campo que ele não
vai informar tá então o que que eu quero
dizer com isso eu quero dizer aqui se
durante a a edição do consentimento por
exemplo você tem um valor definido de
expiration date time um valor definido
de Maximo variable amount e você quer
mover o Maximum variable amount para
Indefinido durante a chamada do do Pet
vai ser passado o os sinais de risco né
que tá obrigatório vai ser passado o
creditors name que também tá obrigatório
e você vai informar o expiration date
time asit exatamente o mesmo valor que
já tá lá na consulta hoje e você não
envia o Maximum variable amount o ato de
não enviar esse campo durante a edição
vai deve ser considerado pelo detentor
como a edição desse valor para
indeterminado ou indein
e esse campo também não vai ser
retornado mais na consulta tá porque por
por ele ser opcional e tá indeterminado
a gente não tem uma representação para
indeterminado para um campo monetário
então por ele ser indeterminado ele não
volta na consulta assim como o
expiration date time ele também não é
obrigatório então se ele tiver
indeterminado e você consultar se você
se o itp consultar um consentimento no
detentor e ele não possui expiration dat
time ou ele não possui Maximum variable
amount quer dizer que os dois estão em
Indefinido né é basicamente isso assim
como se você quiser editar só o
expiration date time você repete o valor
do Maximum variable amount e muda só o
valor do Expression date time
eh bom acho que é isso além disso a
gente tem a alteração do prazo de
inspiração né para 60 minutos do
consentimento então o primeiro aprovador
ou o aprovador único tem até 60 minutos
para aprovar agora tá eu vou pedir para
vocês se atentarem na página da ma
somente pro texto corrido porque o
desenho o texto no meio do desenho ainda
não foi ajustado tá então se vocês
olharem na página da máquina no texto
corrido do status a authorization vocês
vão observar lá essa mudança já hoje E
além disso a gente teve um ajuste
pequeno no objeto de Contract débito
porque a gente tinha só só tava
contemplando ali CPF né e a gente passou
a contemplar também devedoras do tipo PJ
tá pode passaráa por
favor aqui pessoal são algumas das
adições que a gente fez no pagamento tá
adições não né não só adições mas
alterações
eh bom a gente adicionou uma restrição
no transaction identification para
ajustar os critérios de retorno serem
iguais aos critérios de envio tá porque
tinha Algumas casas que apesar de terem
recebido não tava enviando porque o
critério de recebimento era diferente do
critério de retorno da informação então
a gente deu esse ajuste e a gente também
adicionou alguma uma restrição no campo
proxy né atrelando o não envio dele
quando for Manu então deixando claro por
ele ser opcional e ele ter regras de
envio para pros diferentes métodos
instrumentos de liquidação ali a gente
achou melhor delimar claramente quando
ele deve quando não deve ser enviado tá
para evitar confusão eh também foram
adicionados novos motivos de rejeição né
Eu já falei de dois aqui que é o fora
prazo permitido detalhe de tentativa
inválido além disso a gente também tem o
limite tentativas excedido que ele é o a
ser retornado quando a quantidade
contabilizada de tentativas exceder a
quantidade permitida tá então esse é o o
o erro a ser retornado ali caso o itp
tenha caso o itp esteja fazendo mais
tentativas do que o previsto além disso
a gente adicionou o payment reference
Como Eu mencionei para vocês ele vai
trazer o ciclo de referência pro
pagamento né então com exceção ao
primeiro pagamento que ele sempre vai
ter um valor fixo zero né então o
primeiro pagamento declarado ali dentro
do consentimento quando ele foi enviado
pro detentor o a referência dele vai ser
zero então independente do modelo de
agendamento digamos do do intervalo
definido né agora os subsequentes esse
campo vai ter uma regra de preenchimento
diferente de acordo com o tipo de
intervalo definido no consentimento tá
então se for um consentimento semanal o
preenchimento dele Segue uma um padrão
específico se for mensal segue outro se
for trimestral semestral anual assim
respectivamente com padrões diferentes
de preenchimento dá para permitir uma
clareza ali de a que ciclo aquele
pagamento se refere eh é também a gente
teve alteração ali do Lash retri rec
payment AD né quem conseguiu ver a
versão 2 p a Beta 1 da da versão dois
lembra que essa versão tinha um Lash
triver que o payment AD onde ao invés da
gente informar só a original que falhou
a gente informava todas as tentativas
que ocorreram para aquele pagamento né
então a gente achou que era um pouco
over né um pouco demais ter todas eu
acho que todo mundo sabe quais foram as
tentativas né quem quem pediu e recebeu
um ID Sabe qual foi o ID que recebeu e
quem respondeu sabe o que respondeu Sabe
quantas vezes respondeu também eu acho
que a gente entendeu que não era papel
da api trazer essa questão de quantidade
ali é é mais papel de backend de cada
instituição saber quantas vezes foi
criado um pagamento e quantas tentativas
foram realizad eh além disso a gente
teve uma mudança ali também no pet do
pagamento né a gente tava com um
probleminha ali que a gente tava
solicitando o movimento dele para
rejected enquanto que o correto era para
cancelado né quando você cancela um
pagamento o usuário pedindo para
cancelar um pagamento não é uma rejeição
né é um cancelamento
e a gente também adicionou o campo proxy
local instrumente nas respostas de
consulta e na mensagem de retorno da
criação que não existiam tá então tinha
um erro ali na que a gente corrigiu
adicionando esses dois Campos bom
Pessoal espero que tenha sido suportável
tá meu tempo com vocês acho que agora eu
passo a palavra pro bresler é isso
Obrigado José já facilitou bastante meu
trabalho aqui antecipando muitas das
possibilidades que a gente vai tratar
aqui
eh pessoal sou Gustavo bresler sou estou
aqui representando o grupo de trabalho
de experiência do usuário eh Vim trazer
para vocês uma visão geral dos
requisitos de interface recomendo para
todo mundo que
eh não se baseie sua implementação
apenas no que estamos falando aqui
porque aqui a gente tá trazendo
requisitos específicos eh pro PX
automático e que podem ter outros
requisitos também eh da iniciação de
pagamento da confirmação das diferentes
etapas aqui do processo de iniciação de
uma transação de pagamento eh dentro do
grupo de trabalho a gente buscou
incorporar eh ao máximo sempre que
possível eh as mesmas características
que a gente vê no nas definições eh no
arranjo PX quando o pagamento é iniciado
via eh PSP eh porém como foi antecipado
aqui trazendo acomodações para eh
questões específicas do Open funds eh
gosto de ilustrar um caso de uso que é
específico eh do Open finance como um
modelo de negócio por exemplo uma
plataforma em que os seus eh recebedores
cada um tem conta em uma instituição
diferente e ela quer Eh disponibilizar
ali para esses merchants para esses
recebedores a funcionalidade do Pixel
automático é algo que eh seria possível
e viável aqui eh via eh PSI via Open
finance eh a gente vai passar aqui por
eh pelas etapas de solicitação eh que é
realizada na itp eh pela etapa de
confirmação realizada na detentora de
conta e pela etapa eh de efetivação eh
de volta na itp eh e no final a gente
trata também dos requisitos da área de
gestão que que passam a incluir agora eh
questões relacionadas ao pix automático
também eh a gente começa esse cenário da
solicitação com eh algumas
eh alguns cenários aqui possíveis eh
trazendo eh essas telas ilustrativas
para vocês e buscando já também trazer
um contexto adicional das possibilidades
eh e e das configurações possíveis eh
que são permitidas aqui eh nas
autorizações de pixel automático Então a
gente tem um primeiro cenário que embora
ele seja de valor variável eh ali um um
caso de mensalidade eh de uma eh
faculdade eh a mensalidade vai ser a
mesma porém eh eh ela quis ali trazer o
valor previsto e trazer valor variável
para poder eh comportar a possibilidades
de retent ativas futuras eh eh questões
de juros eh ou de multa eh em caso de
pagamentos atrasados Então tá tratando
aqui como pagamento variável porém
trazendo ali eh o valor da mensalidade
de forma prevista para usuário para
facilitar também sua gestão eh ela ela
comporta aqui também um pagamento avulso
imediato que é o caso da matrícula que
tá eh estabelecida ali num valor de R
250 cobrada de forma imediatamente eh um
prazo de autorização definido eh com
começo e fim eh e eh o valor máximo ali
também estabelecido pelo uso usuário eh
que é o valor de de limite máximo
autorizado por mês ali também e
possibilidades de retent ativas em dias
posteriores ao vencimento que trazem
aqui essas informações adicionais ao
final eh da da tela que vocês podem ver
aqui e no segundo cenário aqui eh um
valor eh de pixel automático para
pagamento de uma fatura de energia
elétrica eh e aqui mais simplificado sem
pagamento avulso sem um prazo de
autorização definido Então ela tá ali
por tempo indeterminado ou pela vigência
do contrato como foi colocado eh sem eh
um valor máximo definido pelo usuário
inicialmente tá ali o valor total da
fatura ainda permitindo a ao usuário a
possibilidade de edição do valor máximo
e sem possibilidad de retent ativas em
dias posteriores ao Vencimento da fatura
aqui também então para exemplificar um
pouco para vocês contextos distintos e
agora a gente entra nos requisitos Eh
que foem que compõem aqui essas telas
ilustrativas Iago se você puder passar
por gentileza Obrigado
eh aqui a gente buscou trazer para vocês
de uma maneira simplificada os
requisitos então recomendo que
acompanhem o guia de experiência do
usuário em sua última versão no material
do Open finance e e o usuário ele vai
precisar ser informado inicialmente pelo
menos na primeira utilização as
informações e principais regras do
serviço do pix autom
aqui é uma forma por instituição então
primeira vez que o usuário vai utilizar
o pix automático naquela instituição
pelo menos na primeira utilização que
ele tem ali acesso eh às regras do do
serviço o que que é o pix automático
como que ele funciona a gente tem mais
detalhes no guia também e também aqui é
um espelho do que a gente vê no guia de
experiência do próprio arranjo pix eh
para pros demais tipos de transações de
pix
automático o usuário vai precisar ser
informado da descrição do do bem ou
serviço que é objeto daquele pagamento
daquela autorização aqui eh no campo
additional information que é utilizado
ele tem um identificador da cobrança eh
que pode ser o número de contato o
código do cliente alguma forma que
consiga identificar aquela cobrança
aquela autorização pro cliente eh o
valor dos pagamentos caso eles sejam
fixos de valor fixo a periodicidade que
pode ser estabelecida tanto como uma
data fixa eh uma periodicidade semanal
mensal trimestral semestral anual para
outras formas de pagamento automático
recorrente que a gente teve aqui eh
então aqui eh um ponto importante é que
não tem a periodicidade diária eh a data
prevista para o primeiro pagamento da
recorrência então primeira primeiro
pagamento da recorrência ele tem uma
data prevista Ela não é uma data fixa eh
mas eh que pode aqui incorporar por
exemplo eh um feriado eh um o um dia
seguinte ali caso caia no final de
semana também Eh caso exista um
pagamento Inicial avulso A recorrência
eh aquele pagamento da matrícula ali por
exemplo eh ele precisa ser eh bem
destacado pro usuário ser informado se
ele é se ele é imediato se ele é
agendado e eh existem casos em que o
próprio usuário ele pode editar o valor
daquele pagamento também eh e nesses
casos também da possibilidade de edição
ali para usuário não é obrigatório é uma
possibilidade aqui sempre estabelecida
pelo contrato eh que o usuário pagador
vai ter com o usuário recebedor eh esse
primeiro pagamento Inicial avulso eh
importante que tem ali o objeto eh desse
pagamento ele é referente aqui é uma
matrícula uma tarifa de instalação um
setup eh o valor eh desse pagamento
Inicial e sua data de liquidação também
imediata ou agendada eh o prazo de
autorização que vai ser aqui a validade
do consentimento do pagamento ele pode
ser indeterminado ou determinado sempre
de acordo com o contrato da cobrança eh
ou a preferência do usuário também
quando disponibilizada pelo recebedor eh
vai ter o nome fantasia e o CNPJ do
recebedor eh o nome e CPF mascarado
sempre o CPF eh do pagador aqui vem
mascarado no caso de CNPJ não tem essa
necessidade mas caso o pagador seja eh
uma eh empresa que também traz o CNPJ e
caso aquela etp cobre ali direto do
usuário pagador uma tarifa pelo serviço
de iniciação de transação de pagamento
também precisa ser destacado aqui eh
nesse primeiro momento Então essas
informações gerais e a gente passa a
entrar agora na possibilidade das R
tentativas e dos limites
também se puder passar Iago por
gentileza pro
próximo Obrigado eh
E aí sempre que houver a possibilidade
de tentativas de liquidação do pagamento
após a data do vencimento as retent
ativas que o José abordou agora eh com
possibilidade de três R Tentativas em
até S dias após eh a data do vencimento
eh isso precisa est muito bem destacado
pro usuário inclusive se elas podem
resultar em incidência de juros e multas
que podem podem ser cobradas na fatura
seguinte né no ciclo seguinte eh as
transações futuras eh elas sempre vão
estar sujeitas à disponibilidade de
saldo e do limite do do do pix
automático na efetivação de cada
pagamento isso precisa tá também
disposto pro usuário eh e com relação
aos limites máximos que o usuário pode
estabelecer eh além do limite eh que ele
estabelece na sua própria detentora de
conta eh referente ao a autorizações de
pxs automático como um limite ali eh
Global estabelecido na sua conta eh ele
vai poder definir valores máximos eh
pros pagamentos recorrentes de cada
autorização dele e aí eh cada
autorização vai poder contemplar a
edição desses Campos para que o usuário
possa definir esses limites eles podem
ser descritos como limite por transação
ou limite di perdão aqui não diário mas
um limite mensal eh limite semanal eh de
acordo com a frequência que foi
estabelecida ali no contrato eh e o
recebedor ele também pode estabelecer um
valor mínimo pros pagamentos Então como
foi citado aqui um exemplo no caso do
serviço de streaming eh ele pode citar
ali eh setar um valor mínimo que é o
preço base do produto dele e pode ter
ali eh possibilidades de usuário
aumentar eh ou diminuir o limite para
poder favorecer também planos eh com um
custo maior e disponibilidade de mais
produtos ou serviços para aquele usuário
então eh essas são as as principais
informações que a gente tem disposta pro
usuário no momento da solicitação aqui
realizada eh no
iniciador se puder passar por gentileza
IAG Obrigado eh e quando a gente vai
paraa detentora de conta a gente buscou
deixar aqui eh o o mais exato possível
com o que a instituição também já vai
ter que contemplar de informações pro
arranjo pix em eh eh transações que
foram iniciadas através do PSP recebedor
aqui são os mesmos dois cenários que a
gente trouxe inicialmente naquele caso
eh de uma eh faculdade e de eh Uma
concessionária de energia elétrica eh
são as mesmas informações aqui que são
contempladas então é um valor variável
embora previsto eh ele não vai est
contemplado aqui eh porque eh ele foi um
valor previsto Eh mas você tem eh o
valor máximo autorizado pelo usuário eh
como limite máximo ali diretamente o
objeto do pagamento
código do cliente data prevista do
primeiro pagamento e o início eh e fim
da da autorização eh o pagamento e em
nome da pessoa eh pessoa física ou
pessoa jurídica que tá realizando aquele
pagamento e mais acima os dados do
recebedor também que contemplam eh o a
sua eh o seu nome fantasia caso não
exista o nome fantasia então sim a razão
social mas a preferência sempre pel nome
fantasia e o CNPJ também eh como a gente
tem aqui possibilidade de retent ativas
eh também dispostas as mensagens eh
obrigatórias para eh contextualizar o
usuário a respeito dessa possibilidade
de renta e potencial incidência de juros
e Mora também a gente tem um pagamento
avulso incluso eh no valor de r$ 50
referente à matrícula e a data desse
pagamento ali estabelecida no segundo
cenário aqui também mais simples é igual
o primeiro exemplo então a gente não vai
ter um pagamento avulso ele é por tempo
indeterminado e não teve um valor máximo
definido pelo usuário pagador e ele não
estabelece possibilidades de retent
ativas também então aqui mais simples
também para poder ilustrar para vocês
como esses requisitos eh podem ser
traduzidos em uma interface as
ilustrações que vocês veem no guia são
sempre eh exemplos e e dentro das
possibilidades diz que os requisitos
trazem também trazem a
discricionariedade de cada instituição
de poder construir a sua própria
interface poder passar por gentileza
Iago Iago tá por aí dá passar o slide
por
gentileza foi foi tá Obrigado hender
eh e a aqui a gente traz a a as os
mesmos requisitos eh de da descrição do
bem ou serviço identificador da cobrança
valor dos pagamentos caso sejam fixo a
periodicidade que foi estabelecida eh a
data prevista pro primeiro pagamento
pagamento Inicial avulso prazo de
autorização eh o nome fantasia CNPJ do
recebedor eh o nome e a identificação
CPF ou cnp PJ do pagador Eh caso eh a
gente sabe que em casos de pessoa
jurídica eh as instituições podem cobrar
um valor pela transação do pagamento
também ele tem que tá eh incluído aqui
eh nessa nessa tela eh e eh aqui a gente
traz também a obrigatoriedade de trazer
a instituição que iniciou esse pagamento
essa é uma obrigação geral para todas as
iniciadores de transação de pagamento em
todos os tipos de eh iniciações de
transação de pagamento eh mas ela
costuma ser uma recomendação para outras
formas de pagamento eh eh na como
requisito aqui com é uma recomendação
para as detentoras de conta na tela de
confirmação eh Então nesse caso aqui a
gente Traz essa obrigatoriedade e também
eh as regras de renta tia eh que caso
conforme foram definidas pelo usuário
recebedor ali caso elas existam eh então
mesmo formato a gente buscou trazer aqui
também eh a mesma nomenclatura inclusive
eh eh que foi utilizada no guia de
experiência do arranjo
pix e quando a gente tem eh a gente traz
aqui alguns requisitos adicionais e e
também questões relacionadas a
notificações para as detentoras de conta
esses parâmetros eh que são
estabelecidos na autorização e que vão
pro momento da confirmação eles não
devem estar abertos a edição ali é é
confirmação ou cancelamento daquela
autorização eh eh o as notificações
dentro do arranjo pxs eh relativas às
autorizações de pix automático elas
passam aqui a ser realizadas pela
iniciadora Então nesse momento elas são
desabilitadas por padrão na detentora de
conta dado que o canal eh que o usuário
utilizou para realizar aquele pagamento
ali foi a iniciadora de transação de
pagamento eh o usuário porém ele tem a
possibilidade de habilitar dentro dos
parâmetros da autorização na sua área de
gestão aqui dentro da da iniciadora
também eh as notificações caso ele
prefira receber essas notificações ali
através eh do do da instituição que
detém a sua conta
eh caso um pagamento eh tenha sido
agendado e ele não tenha sido efetivado
por uma falha operacional ali após o
envio da ordem de pagamento eh na última
tentativa de liquidação a detentora deve
também notificar o usuário nesses casos
específicos informando que não foi
possível efetuar o o o pagamento dele
por meio do Pixel automático devido a
uma falha operacional eh e aí eh também
orientar o o usuário a entrar em contato
com o recebedor ou a empresa que
intermediou o pagamento para efetuar o
pagamento por outros meios também ela
não pode ali ofertar uma alternativa
própria puxa eu tenho aqui a chave pix
desse recebedor quero eh você quer fazer
um pix direto para esse recebedor eh eh
eh isso é impossibilitado porque eh fug
giria ali eh das potenciais eh eh
definições que foram estabelecidas em
contrato se o recebedor tá utilizando
ali algum sistema para realizar os seus
pagamentos eh e fazer a conciliação dos
seus pagamentos esse pagamento por por
exemplo não seria identificado Eh caso a
confirmação de uma autorização ela
esteja pendente eh da confirmação do
usuário dentro daquele prazo exigido na
regulação eh a a detentora ela deve
notificar eh o usuário informando quando
esse pagamento esse essa autorização foi
processada eh e confirmada então Eh um
exemplo aqui eh eh por exemplo de
múltipla açada ou Que ficou pendente ali
dados uma avaliação de risco eh de
temporizada eh é o a detentora depois
tem que eh notificar o usuário de que
aquela confirmação foi de fato
processada e
autorizada poder passar por gentileza
Obrigado eh e aí quando o usuário ele é
redirecionado de volta após ter feito
autorização eh ali no ambiente da eh
iniciadora de transação de pagamento Eh
caso exista ali um pagamento Inicial
avulso e ele foi imediato é obrigação da
iniciadora já eh apresentar pro usuário
o comprovante daquele pagamento caso ele
tenha sido do agendado o comprovante
desse agendamento também eh se o
consentimento ficou pendente de
aprovação de múltipla alçada informar o
prazo de aprovação eh que pode ser
estipulado ali junto com o recebedor
Então se o recebedor falar ah não se
ficou múltipla alçada eu não quero eh eh
Pode cancelar essa autorização então ele
ele seria cancelado eh e se eh Se o
recebedor não estipular nenhum tipo de
prazo ali eh que ele estaria confortável
em receber a confirmação dessa
autorização o prazo máximo para
autorizações eh pendentes de múltiplo
alada é de 30 dias e é esse o prazo que
deve ser eh mostrado pro usuário pagador
caso ele não tenha sido estipulado no
contrato pelo recebedor eh as
notificações eh vão ser enviadas pro
usuário quando os próximos pagamentos
forem agendados a iniciadora precisa
informar eh o usuário eh dessa questão
também informar que o recebimento de
notificações dos agendamentos eles podem
ser desabilitados eh o cancelamento da
autorização pode ser realizado a
qualquer momento o valor máximo dos
pagamentos ele pode ser alterado caso
ele eh seja estabelecido eh e os
pagamentos estão condicionados à
disponibilidade de saldo de limite eh da
da autorização do pix automático Eh
esses pagamentos futuros eh o e também
informar o usuário que o uso de limite
de crédito aqui falando de cheque
especial mas qualquer tipo de limite de
crédito disponível que o usuário tem ali
eh em sua instituição eh paraa
realização de pagamentos por meio do
Pixel automático ele também pode ser
desabilitado mas aí diretamente na sua
instituição detentora de conta eh na
área pix ali buscando por essa
autorização
eh a iniciadora ela passa aqui a assumir
responsabilidades que são designadas eh
no manual de experiência do PX para o
PSP do pagador quanto ao envio da essas
das notificações relativas a essa
autorização ela vai ser o principal meio
de contato ali para com o usuário
pagador eh de todas as questões que
estão relacionadas à sua
eh a sua autorização eh aqui
estabelecidas então de acordo com o
regulamento pix os casos são de toda vez
que tiver um agendamento de transação
toda vez que um pagamento for efetivado
se um pagamento não for efetivado por
insuficiência de saldo ou de limite
disponível para pix automático eh
tentativas de cobrança após a data do do
vencimento eh pagamento não efetivado
após a última tentativa de liquidação
possível ali passados aqueles aquelas
três Tentativas em 7 dias eh o pagamento
não foi efetivado por falha operacional
após a última tentativa pagamento não
foi agendado porque ele ultrapassou o
limite máximo estabelecido naquela eh
autorização ou então era uma autorização
de valor fixo e foi um valor diferente
do valor fixo estabelecido eh o
pagamento ele não foi agendado por
instrução eh eh porque a instrução do
pagamento não foi enviada no prazo pelo
recebedor eh o agendamento foi cancelado
por iniciativa do próprio recebedor eh a
a o cancelamento a autorização também
foi cancelada por iniciativa do
recebedor e a autorização pendente de
conformação seja ela processada ou
excluída então todos esses casos aqui
vocês vão ver mais detalhes eh
referentes a cada um desses casos no
guia de experiência do usuário eh do
Open finance Brasil e e são eh passam a
ser obrigações aqui do iniciador
assumindo essas responsabilidades do PSP
pagador como é estabelecido no manual de
experiência do pix a forma de envio
dessas notificações é de livro escolha
do iniciador ela pode ser feita por push
notification por mensageria por e-mail
de acordo com eh o o canal ali que ele
tem para para junto daquele daquele
usuário pagador
e agora passando paraa área de gestão a
gente traz requisitos eh que vão ser
tanto da detentora de conta quanto da
iniciadora eh e quando não for eles vão
est eh bem especificados aqui no no nos
próximos slides Então as duas
instituições devem disponibilizar pro
usuário pagador o histórico dos seus
consentimentos com as autorizações que
estão ativas pendentes inclusive de
múltiplo inspiradas ou que foram
canceladas E aí com a data da
autorização e de inspiração ou
cancelamento eh E também o histórico
dessas movimentações por consentimento
ativo Então se o usuário clicar numa
autorização que está ativa expirada ou
cancelada ele vai poder ver ali as
informações mínimas de cada transação
que foram feitas dentro daquela
autorização e por se tratar de um
produto que ele é específico dentro do
Open finance Open finance
sempre tratou eh o o os meios e métodos
de pagamento de maneira agnóstica Porém
Aqui é um produto que é específico do
arranjo pix e que já contempla a sua
área pix então eh a gente entendeu por
bem que eh faria mais sentido para que
as detentoras de conta trouxessem eh
essa área de consulta e de a de gestão
das autorizações de pagamentos de piques
automático eh na no mesmo local em que
elas vão disponibilizar essas alterações
eh essas autorizações Quando forem
criadas eh via PSP recebedor via arranjo
pix então Independente se foi criado eh
via Open finance via uma iniciadora de
transação de pagamento ou se foi criada
via PSP recebedora arranjo pix todas as
autorizações vão estar no mesmo local
ali eh Possivelmente potencialmente a
área pix daquela instituição que ela vai
ter ali disponibilizada paraos seus
usuários eh de forma a não confundir o
usuário e unificar experiência nesse
produto que tem essa particularidade
também eh as autorizações e
movimentações que forem realizadas via
Open finance elas podem opcionalmente eh
estar disponibilizadas pro usuário
pagador no ambiente da área de gestão
Open finance daquela instituição também
é uma opção a obrigação é que esteja ali
eh na área PX junto com as demais
autorizações realizadas eh eh dentro do
arranjo ali via PSP recebedor
E aí eh já antecipando a parte das
alterações potenciais e que já foram
aqui eh muito bem faladas pelo José eh o
usuário pagador ele vai dispor dessas
funcionalidades de alteração para essas
autorizações consentimentos embora a
área de consulta da detentora de conta
vai ser a mesma quando ele clicar na
autorização ele vai ter essas distinções
eh para poder acomodar as possibilidades
aqui que são tintas entre eh as duas
origens de de autorização para o usuário
pagador então
Eh com relação ao prazo de autorização e
a data do primeiro pagamento eh na
detentora de conta eh São informações
que são passíveis de visualização e na
iniciadora elas são passíveis de
visualização e de edição se assim for
permitido no contrato junto aquele
recebedor na na que que é o que rege
aqui eh os demais parâmetros também o
valor máximo ele é desabilitado por
padrão então sempre Eh caso ele esteja
desabilitado ele vai permanecer
desabilitado eh e e limitado sempre ao
valor mínimo estabelecido pelo recebedor
para aquela autorização porém ele é
passível de visualização e de edição
tanto na detentora de conta quanto na
iniciadora a utilização do limite de
crédito eh ele eh que aqui contempla
também um cheque especial ele é sempre
habilitado por padrão e passível de
visualização e edição apenas na
detentora a iniciadora não tem eh a a
visibilidade ali eh se o usuário tem eh
o seu limite de crédito
eh habilitado ou não e também não pode
eh ofertar essa edição pro usuário as
notificações elas vêm desabilitadas por
por padrão na detentora mas a a
detentora ela pode ali eh permitir que o
usuário receba notificações referentes a
essa própria instituição e na iniciadora
elas passam a ver habilitadas por padrão
eh e também são passíveis de edição para
que o usuário receba notificações
relacionadas a essa própria instituição
então cada instituição eh apenas
habilita as suas próprias notificações e
elas podem eh eh est habilitadas em
ambas as instituições ou desabilitadas
em ambas as instituições
também ainda seguindo na parte de
alterações eh alterações relativas a
parâmetros que foram estabelecidos no
consentimento Como José bem disse Eles
apenas podem ser realizados por usuários
com plenos poderes então caso a uma
tentativa de alteração seja realizada na
iniciadora tem um um código de erro
específico eh que e deve ser tratado
para informar o usuário pagador dessa
impossibilidade eh de alteração e apenas
e orientando que apenas o o os usuários
com plenos poderes poderiam realizar
essa alteração eh o usuário recebedor
ele vai poder alterar o seu nome
fantasia caso o valor do débito seja
variável sempre alteração desse valor do
débito eh de acordo com o serviço
prestado e não tenha necessidade de um
novo consentimento eh quaisquer outros
parâmetros da recorrência que não foram
citados aqui anteriormente eles vão eh
necessariamente requerer um novo
consentimento do pagador E cabe a ele
aceitar esse consentimento ou não eh
todas essas questões a gente trouxe aqui
também uma visão geral e vocês podem ver
mais detalhes a respeito delas no guia
de experiência do usuário também e
passando paraa última parte que é a
parte de revogação eh então na área de
de gestão usuária ele deve sempre ser
capaz perdemos o brv
voltou pessoal desculpa Desligou o fone
aqui eh então Eh retomando na área de
gestão a ações relativas à revogação o
usuário sempre deve ser capaz de revogar
o consentimento de pxs automático tanto
na na Instituição iniciadora quanto na
detentora de contas eh e o usuário deve
ser capaz de cancelar os agendamentos
que já foram realizados que ainda não
foram efetivados eh para agendamentos de
pixs automático eh o usuário ele pode
cancelar um agendamento até às
23:59 do dia eh imediatamente anterior a
sua liquidação eh então Eh deu
meia-noite já é já virou o dia da
liquidação do pagamento ele não pode
mais cancelar aquele agendamento mesmo
que ele ainda não tenha sido efetivado
eh e aqui eh também reforço que a gente
tem mais informações a respeito de dos
outros requisitos da área de gestão que
passam eh que também a com o pix
automático no guia de experiência do
usuário do Open finance Brasil e
acredito que aqui da da com relação à
área de eh experiência do usuário é tudo
que a gente tem para hoje se alguém
tiver alguma dúvida também quiser deixar
no no chat aí eu vou est acompanhando
obrigado boa obrigado bresle acho aqui
passando já pra próxima
pauta os tempo aqui também não não tá
muito longo tinha previsto
as 4 horas já passo direto aqui a
palavra pro Cris vai falar um pouco
sobre motor de conformidade
funcional Opa boa tarde pess V Obrigado
Iago eh acho que eu Provavelmente vou
até puxar a tela aqui eu apresento
porque eu vou ficar indo na planilha e
no motor
e Ô vocês estão vendo a tela agora já
est sim bo obrigado é pessoal bo Boa
tarde e me chamo Cristian Eu trabalho na
rid né A gente trabalha aqui junto com
estrutur junto com GTS na construção do
motor de conformidade algumas
ferramentas aqui do ecossistema eh hoje
seguindo aí a linha do workshop A ideia
é gente falar sobre os testes de eh
pagamentos automáticos V2 né os testes
como a gente tá vendo né Tem muitas
funcionalidades muita coisa para ser
testada muitas regras Então os testes a
gente tentou ser o mais exaustivo nesse
sentido né de testar todas as
funcionalidades de testar todos os cases
obviamente que tudo é impossível de ser
testado né mas você acho que passando
aqui vocês vão ver que a gente conseguiu
abranger uma grande parte ali do de de
tudo que existe na pi né Eh acho que um
ponto importante antes de entrar aqui né
que o motor hoje para eh para para V2 né
automátic pento V2 ele já tá disponível
no motor de conformidade só que a gente
tá agora na Beta 1 né então a gente tá
num processo de transição para beta2 que
a previsão de Deploy provavelmente vai
ser na semana que vem né o início Deploy
na semana que vem até o dia 2 é no dia
2is o o a a data para Deploy da beta 2
de Fato né falando isso porque acho que
vou passar aqui né Acho que o Zé
comentou bastante também lá mas tem
muitas alterações que até quebram os
testes quebram a implementação porque o
campo mudou do mudou de lugar mudou de
nome enfim só para quem tá nesse
processo de teste fica atento com isso
Eh mas enfim falando sobre os testes em
si né todos os testes essa planilha aqui
tudo isso que eu vou falar também ele tá
disponível lá no gitlab também para
acesso eu coloquei o link no chat já
então quem quiser ir abrindo vendo no
paralela planilha os testes também por
favor fica à vontade eh essa nova versão
né quando a gente tá falando da V2
pagamentos automáticos a gente tem dois
produtos né que hoje estão dentro dessa
dessa api né sendo sweeping accounts que
é transferência inteligente e a segunda
é o Pixel automático né E aqui quando a
gente fala dos Testes né a gente apesar
da V2 tá introduzindo majoritariamente n
essas features essas características na
pi para API de pix PR pro produto de
pixel automático né Por Algumas
estruturas serem compartilhadas como a
estrutura de consentimento por
exemplo isso traz alterações na
funcionalidade de sing também né então
enfim eu vou comentar aqui mas a gente
pros testes né Isso vai incluir um novo
plano de sweeping né então a gente tem
sweep account V2 que vai ter que ser
recertificado e toda a parte de pixel
automático V2 né então a gente tem
transferências inteligentes e pixel
automático acho que esse é um ponto que
é bem importante do pessoal ficar atento
vou comentar sobre as diferenças aqui né
su accounts não tem mudanças muito
estruturais mas tem mudanç
eu vou comentar um pouco sobre elas aqui
e enfim entrando então nas mudanças né
falando sobre plano de swiping né a
gente tem os testes de Sing a gente tem
três planos eh que vão precisar ser
realizados pra certificação né sendo
Primeiro Plano padrão né onde a gente
tem 16 testes e o segundo um plano de
time Zone então pra gente testar aqueles
cenários onde a gente tem a questão uma
diferença né de fuso horário entre o
momento do pagamento criação do
consentimento melor o que a gente tem na
v4 também e webhook acho que como é de
de prática aqui também pra gente testar
a funcionalidade de webhook eh e aí 16
testes um teste quatro testes né falando
sobre o plano padrão né são poucas
alterações em relação a V1 eh digo com
relação a mudança do teste em si eu vou
mostrar aqui os testes de swip mostrar o
teste que alterou Mas o comportamento
dos Testes em si né ele praticamente não
alterou acho que só teve um teste que
teve alteração de fato e que é
relacionado essa estrutura do consen mas
nos demais os testes são os mesmos a
diferença é aqui né a gente vai chamar
V2 né então o pef lá vai tá no V2 e a
gente tem essas mudanças de nomeclatura
e do Campo né E aí um exemplo acho mais
claro aqui é relativo ao start date time
né start date time saiu do Rot do data
né que antes era data P start date time
dentro do Jon Isso mudou para dentro do
swip né então Eh como a gente também não
aceita Campos adicionais dentro das apis
é muito provável que se alguém
implementou a ver um só replicar né vai
receber erros nos testes porque os
testes já vão estar mandando nesse novo
formato aqui né Principalmente relativo
a a Beta 2 né que introduz essas
alterações
eh então esses 16 testes né mas vou me
ater pouco a eles porque são testes bem
parecidos a gente teve a introdução
desse novo plano aqui de timezone que já
tá algum tempo no motor Então pode ter
eventualmente alguém executou isso mas
não tava sendo exigido paraa
certificação que é um plano de gestão de
time Zone né então a gente tem aquela
diferença que algumas horas dentro do
payload elas são feitas no horário TC né
E algumas são feitas em O tc-3 que é o
horário de Brasília e essa esses dois
horários precisam casar né Essa
conversão precisa ser feita ali do lado
da detentora eh então é basicamente
fazer um pagamento com sucesso entre 9 e
23 horas né entre 9 e mei que é quando
dá essa diferença eh de horários enfim
um horário poderia jantar pro dia
seguinte na teoria mas na prática é só
uma diferença de time Zone e por último
test web Hook bem similar a sem mudar na
prática a não se essas questões de
payload e estrutura e nomenclatura dos
Campos que que foi feito né então do
plano de sweeping como eu comentei não
tem alteração nos testes né relevantes
teve o único teste que foi alterado esse
aqui que a gente teve uma alteração onde
antes tinha um requisito de que o
consentimento precisava expirar dentro
de 5 minutos né então uma vez que o
consentimento era criado e ele ficava em
await autorisation né esperando o
redirecionamento do usuário esse
consentimento inspirava em 5 minutos e
agora ele não inspira ele pode ir até 60
e tem alguns critérios que foram
adicionados na pi lá também então a
única alteração que a gente fez foi que
em um dos Testes a gente vai esperar 7
minutos né então teste que vai acabar
demorando um pouco mais para ser
executado mas só para garantir que com 5
minutos esse consentimento não vai ser
inspirado né não vai ser não vai para
rejected ali né o usuário vai conseguir
continuar o processo ali de aprovar o
consentimento mesmo depois se demorar 5
minutos entre momento da criação do
consentimento que é o post Constant e o
momento do redirecionamento do usuário é
então enfim es queit suping accounts é
basicamente essa mudança né no plano de
teste eí lembrando tem os três planos
esses três planos são necessários para
certificação acho que o Yago vai
comentar um pouquinho mais sobre isso
depois também mas bem importante pro
pessoal se atentar tanto a questão de
pix automático quanto plano de swip né
dado que isso tem essas alterações em
Campos os campos mudaram de lugar e teve
essa nova alteração aqui nos testes né
Mas o comportamento majoritariamente é o
mesmo né acho que não é para ser uma
digamos assim uma implementação muito
custosa nesse sentido dado que a gente
já fez a maioria desses comportamentos
na
v1 falando então de pixel automático né
que eu acho que é o foco principal aqui
a gente tem quatro planos eu vou falar
de três planos aqui e vou falar de outro
plano na sequência aqui que é o plano de
retra né a gente tem várias
eh vários pontos ali né que que vão ser
verificados então a gente tem falando de
que se a gente fosse quebrar né em
algumas macro features assim né a gente
tem toda a funcionalidade de pixel
automático que de fazer o pagamento a
gendar um pagamento né nas diferentes
periodicidades a gente tem a parte de
edição de consentimento eh e a gente tem
a parte de webhook e a gente tem a parte
de R tentativas né que foi o que o
pessoal comentou aqui anteriormente e a
gente tem pro Pixel automático quatro
planos separados é esses planos também
né a estrutura dos planos ela foi feita
para facilitar o processo de testagem eh
acho que desses né O que vai ser mais
diferente eu vou investir um pouco mais
tempo aqui para pra gente conversar
sobre são os testes de retra mas bem
importante também todo mundo ter visão
do número de planos e a não acabar enfim
chegando perto do momento da
certificação descobri que tinha um plano
que eu não tava fazendo Enfim acho que
isso tudo aqui também material vai ficar
disponível né acho que isso aqui vai ser
já já foi né E vai ser disponibilizado
via informa também e tem eu mandei a
planilha dentro do chat né mas
importante todo mundo ter tracking de
todos esses planos né que é sweeping
account V2 todos os planos Pixel
automático V2 todos os planos n então
falando de pixel automático né a gente
tem um plano que seria o plano padrão
onde a gente tem 26 tches
dentro desses 26 testes a gente tá
testando o comportamento de cenários
felizes e infelizes incluindo os testes
de edição de consentimento Então esse
bloco de edição de consentimento ele tá
dentro desse plano padrão eu vou passar
pelos testes no instante tem um plano de
time Zone também então bem similar a
esse teste que a gente comentou para
sweeping né a gente vai ter um teste
paralelo eh para pix automático mesma
coisa né garantir que esses pagamentos
dentro de diferentes time zones podem
ser realizados e E aí um teste executado
ali entre 9 2359 né então a tentar o
horário de execução do plano e e por
último teste e o plano de webhook né a
funcionalidade webhook né a gente tá
entendendo que ela já tá sendo
majoritariamente testada né os ent
points são os mesmos ela já tá sendo
majoritariamente testada dentro de autom
dentro do sweeping accounts né então
para esse teste para esse plano de web
Hook para Pixel automático a gente tá
focando Principalmente nos cenários que
não são cobertos dentro do sweeping eh e
acho que o principal caso né que eu acho
que vai ser um pouco diferente é o caso
de Pag os agendados né então pagamento
agendado quando ele chega em Schedule
ele precisa emitir uma notificação web
Hook e em sweeping a gente não tem
agendamento de pagamentos né então é uma
nova dentro de webook é uma nova feature
digamos assim que também tem que ser tem
que ter atenção né então vou passar pra
planilha aqui e mostrar a planilha e
depois eu volto para falar dos Testes de
retry E então falando dos dos Testes né
de pix automático e a gente vai ter aqui
os planos Core né os módulos Core que
são módulos padrões e é só trazendo
também um pouco né Essa essa planilha
que tá lá né da beta 2 ela é um pouco a
descrição também do teste do que mudou
do teste da Beta 1 para beta2 Então se
já tem alguém desenvolvendo em cima da
Beta 1 e enfim a gente vai ter o
lançamento da beta2 e os Marcos vão ser
cobrados a partir da beta 2 são mudanças
bem significativas né E aí essa
descrição Por exemplo quando tá em
vermelho aqui isso foi retirado do teste
quando tá em verde aqui isso foi
adicionado no teste n só dando clareza
ali do que que são esses símbolos que
vocês vão ver dentro das planilhas ali
para facilitar tá enfim a consulta eh
Então a gente tem os testes Core aqui né
que são os testes padrões né então a
gente vai ter para todas as os
periodicidades possíveis né então um
teste onde a gente faz esse pagamento e
agendamento anual semestral eh
trimestral mensal semanal né diário a
gente não tem como o pessoal comentou
mas aqui teste simples né testes padrões
onde a gente cria um consentimento com
um first payment né um pagamento da
matrícula faz o pagamento da matrícula
agenda o primeiro pagamento respeitando
todas essas janelas que foram comentadas
né de 2 a 10 dias etc eh o estado né
Desse first payment a gente geralmente
tá fazendo first payment imediato Então
a gente vai ter que cumprir um pagamento
né vai ter que fazer um pagamento de
início e e esse pagamento vai ter que
ser aceito e aí na sequência a gente a
gente prossegue pro agendamento do
pagamento e o agendamento do pagamento a
gente encerra o teste quando a gente
Verifica que ou ele tá agendado eem
alguns testes a gente cancela também na
sequência né então a gente por exemplo
falando aqui do teste mensal que é muito
similar a esses testes de padrões a
gente faz deixa eu aumentar um pouquinho
aqui
eh aqui a gente faz o primeiro post né e
a gente espera um pagamento aceito então
a gente cria o consentimento faz um
primeiro post aqui post payment E aí
esse primeiro pagamento é aceito na
sequência a gente vai fazer um outro
post que é para agendar esse segundo
pagamento né o primeiro pagamento da
recorrência na sequência a gente cancela
e verifica se o pagamento foi cancelado
né dá um get lá e verifica se foi tudo
conforme o esperado eh Então esses
primeiros módulos aqui né módulos bem
simples acho que acredito que uma vez
que a gente tenha a feature né
adicionada não deve ter muito trabalho
para mudar a periodicidade acho que tem
essas questões dos cálculos do payment
reference que tem que ser validado né um
campo acho que o pessoal comentou também
né que esse controle da de qual
pagamento está sendo feito né tem um
campo dentro do payload que é o dentro
do post payments né que é o payment
reference que ele é opcional mas ele é
obrigatório para pagamento de pixel
automático esse campo aqui e aí dentro
desse Campo é que a gente vai fazer o
controle se é o primeiro pagamento da
série se é um pagamento trimestral né
ele se utiliza em relação a qual
trimestre se é o Q1 Q2 Q3 então é
importante também eh estabelecer essa
validação né um campo opicional que é
uma string Mas elas T uma regra de
negócio bem
eh complexa digamos assim né comparado
com os outros então bastante atenção
nesse Campo também aqui para questão dos
Testes
eh na sequência a gente começa a ter
cenários infelizes né alguns cenários
felizes infelizes então aqui basicamente
fazer um agendamento Sem Limites na
sequência eh a gente tem essa questão de
dois a a a 10 dias né que tem que ser
feitos ali que eu eu só posso fazer o
agendamento dentro desse período n não
posso fazer um agendamento para daqui a
um mês nem posso fazer um agendamento
para amanhã então a gente tenta fazer um
pag um agendamento para antes de dois
dias e um agendamento para depois de 10
né então garante que esse esse esse
tempo tá sendo validado eh na sequência
alguns testes relativo a crédito né
então como o pessoal comentou né a gente
tem essa característica de precisar de
informações da conta acreditada ali do
recebedor né enfim de dados do do
similar o que a gente tem acho que a
diferença aqui é que o creditor no caso
vai ser esse recebedor né então vai ser
o serviço de streaming vai ser enfim
aquele serviço que tá recebendo esse
pagamento academia etc né então a gente
tem alguns testes também que testam
algumas características desse Campo de
crédito né E aí esse teste pode ser
descasamento entre consentimento e
pagamento eu vou falar aqui pois subst
de crédito né mas então a gente informa
um crédito no momento do consentimento e
tenta fazer um pagamento para outro
crédito eh tem também a gente Envia um
creditor aleatório Então esse creditor
não vai tá ligado àquela conta debitada
né enfim aí tem a questão de consulta
dentro da estrutura do PX que tem que
ser feito esse tipo de coisa
eh enfim esses des casamentos que que
são feitos ali que a gente tá testando
né então wrong creditor a gente coloca
creditor account como um número
aleatório né eu vou comentar aqui depois
também sobre a setagem do plano mas esse
o número do crédito ela vai ser setado
na configuração do plano então aqui a
gente vai usar um número aleatório para
isso eh invalid creditor né a gente aqui
na prática tá quebrando algumas regras
né então por exemplo a gente tem suping
accounts Que contas PJ podem ter mais de
um crédito né dentro do payload e aqui a
gente só pode ter um para Pixel
automático então a gente joga com esse
ponto justamente para ver que dado que a
estrutura de consentimento ela é a mesma
né o post conen é o mesmo e grande parte
do payload é o mesmo paraos ambos os
produtos é importante que a gente quebre
essas regras de negócio para o que são
regras de negócio de pixel automático e
o que são regras de negócio para swip
accounts né então o campo creditor por
exemplo dentro do post cons ele vai ele
vai se comportar de maneira diferente
para um produto e para outro então a
gente basicamente tá fazendo essas
validações aqui
eh testes de consentimento negativo
então aqui é mais não mandar Campos
obrigatórios Enfim acho que é um teste
um pouco mais simples também né pensando
na jornada de implementação né são
testes que a gente até recomendo pro
pessoal começar achar que são erros
síncronos no consentimento então é mais
simples também de implementar
eh parâmetros Inválidos então de novo né
alguns parâmetros ali mais voltados ao
tipo de parâmetro testes simples também
erros síncronos no consentimento são
testes que a gente recomenda o pessoal
começar a jornada de implementação né
que acho que vai ser o primeiro ponto
que pode ser implementado uma vez que eu
já tenho a estrutura de consentimento lá
eh aí como algumas questões né com a
questão de limite e a questão do Fix
Mount né Ach que como o Zé comentou a
gente tem dois tipos de pagamento um
sendo fixed amount então eu faço um
pagamento fixo né E aí outro sendo a
questão dos limites lá então eu posso
estabelecer um limite máximo e limite
mínimo dentro do qual eu posso executar
esses pagamentos né então e aqui a gente
tenta fazer um pagamento diferente do
fixed amount E aí espera uma falha aqui
a gente tenta fazer um pagamento menor
do que o mínimo variable amount e aqui a
gente tenta fazer um pagamento maior do
que o máximum variable amount né então
se se o pagamento for fixo o valor tem
que ser exatamente aquele se eu tiver
limite eu tem que est dentro do limite
eu não posso estar nem acima nem abaixo
Então são testes nesse sentido eh o
start date time né aqui o reference
start dat time já teve essa mudança no
nome do campo eh basicamente garantir
que eu não posso executar um pagamento
se ele tiver antes do reference do
reference start time né então preciso
respeitar isso para fazer o pagamento do
agendamento da da série
eh na sequência teste de creditor também
né Então essas questões de crédito que
eu comentei anteriormente eh
consentimento revogado então eu garanti
que um pagamento agendado ele é
rejeitado quando o consentimento é
revogado né Então Eu agendei um
pagamento por exemplo para n daqui a
três dias e aí no meio desse tempo antes
desse pagamento ser efetivado né que
chegar esses três dias o usuário
rejeitou o consentimento ele revogou o
consentimento então isso eu preciso
tanto rejeitar a estrutura do
consentimento Quanto cascatear isso para
todos os pagamentos agendados né então
acho que é uma questão nova aqui nos
produtos que essa questão do agendamento
de pagamentos um a um né na v4 a gente
já tem agendamentos Mas é da recorrência
como um todo então acho que era mais
fácil fazer Essa gestão então um ponto
de atenção aqui também com relação a
isso né de cascatear essas dependências
entre consentimento paraa estrutura que
existe dos pagamentos né os pagamentos
agendados e tudo mais
eh na sequência né A questão de first
payment né então a gente tem eh
eh algumas questões com relação ao
primeiro pagamento né porque aqui a
gente tem de novo né uma característica
diferente do produto é que a gente tem
essa esse primeiro Pag pagamento e tem o
pagamento da série né E aí o primeiro
pagamento tem regras de negócio e os
pagamentos da série tem outros tem
outras regras né e enfim Isso precisa
ser adotado né A forma como pode ser
feito isso né usando por exemplo o
payment reference sempre que for o
primeiro pagamento né Isso aqui vai ser
informado como zero então regra de
validação do payload né é um campo que
pode ser usado por exemplo aqui né para
para fazer essas regras de validação do
payload se é o primeiro pagamento como
eu valido se é um pagamento da série
como eu valido Mas enfim e critério das
instituições a melhor maneira de definir
essa arquitetura é mas só é importante
notar de que as regras de negócio são
diferentes pro first payment e pros
outros pagamentos né pros pagamentos da
série então aqui são alguns pagamentos
eh algumas características com relação a
esse primeiro pagamento o agendamento
dele no futuro e que um first payment
também não pode ser executado com uma
conta acreditada diferente então de novo
né que um pouco essa questão das contas
creditadas então divergente do
consentimento contas inválidas contas
aleatórias tudo isso é importante ser
validado né dado que é a conta que o
dinheiro tá indo aí edição de
consentimento vou falar num instante só
queria passar mais dois testes que estão
aqui embaixo que é essas questões também
do first payment o first payment ele tem
uma característica que é first payment
de novo né o pagamento da matrícula né E
tem uma questão do pagamento da série
com relação a esse first payment né Eu
só posso agendar um pagamento da série
depois que o first payment Depois da
data prevista pro first payment né então
mas se o first payment falhar eu preciso
conseguir agendar o primeiro da série né
E aí tem toda essa questão que que o
José trouxe ali de enfim como que vai
ser feita se ele quer revogar esse
consentimento ou se ele não quer e se
não ficou uma definição vai ficar
critério um pouco ali do recebedor do
pagador enfim de sear esses parâmetros
mas acho que os dois pontos importantes
aqui é né se eu cetei o first payment
para d+ 30 eu não posso agendar um
pagamento para d+ 3 né então eu preciso
esperar esse first payment ser feito
para eu poder agendar Esse é um primeiro
ponto e o segundo que se por exemplo se
Eu agendei o primeiro pagamento o first
payment né para D mais 30 ou seja para
daqui a um mês passou um mês o primeiro
pagamento Falhou Eu preciso conseguir
agendar o primeiro da série né então é o
que a gente faz aqui a gente cria um
pagamento um first payment que falha e
depois na sequência eu tento agendar um
primeiro da série né e agendamento tem
que acontecer e Então esse é o plano
Esses são os testes do plano padrão
digamos assim né e um outro grupo que tá
aqui é a parte deção de cons
Então acho que um ponto importante aqui
né que conforme o pessoal comentou essaa
essa questão de que se o campo não foi
enviado né ele significa que eu tô
estendendo esse parâmetro para infinito
então é importante que eu como
iniciadora né replique a estrutura do
consentimento atual se eu quiser mudar
um campo eu preciso pegar tudo como é e
só mudar aquele campo e mandar tudo de
volta né como se eu fizesse um crud da
base tivesse salvando de novo né então
eu preciso
Eh preciso enfim acessar esse dado mudar
o que eu quero e depois enviar de novo
ali e E se eu não mudar isso vai para
isso vai para vai para infinito né então
tem teste de edição de consentimento um
para mais permissivo outro para menos
permissivo aqui são testes mais simples
acho que um teste importante de
ressaltar esse teste de account holder
né então tem algumas características de
edição de consentimento que são feitas
direto na detentora né então por exemplo
se tá um limite máximo se eu não tiver
setado quando eu criei o consentimento
isso não pode ser feito pela iniciadora
Então se o usuário no momento do
direcionamento não setar um limite se
ele quiser setar um limite depois ele
tem que fazer direto na detentora né é
um exemplo eh e aí esse teste aqui o que
a gente vai fazer é que exige uma ação
do usuário fora do teste Então a gente
vai criar um consentimento esperar 10
minutos e esperar por essa edição do
consentimento do lado da detentora né
enfim a gente não monitora iex a gente
não monitora se vai tá sendo feito por
uma interface o importante é que esse
campo possa ser alterado do lado do get
ali né do lado da da da detentora de
conta eh
Marcos acho que Você levantou a
mão levantei tudo bem e cara você pode
por favor repetir aqui a a regra que
você falou eu fiquei meio confuso Claro
eh você disse com relação a edição de
consentimento isso exato tá boa essas
regras de edição de consentimento elas
estão nessa página aqui de edição de
consentimento e onde você consegue ver
todos os campos que podem ser editáveis
E aí tem dois dois
eh dois grupos né Campos passíveis ção
na iniciadora e Campos passíveis de
edição na detentora né essa regra
específica que eu citei é porque se
vocês olharem aqui os campos passíveis
de edição na iniciadora ela inclui
aumentar o valor ou reduzir o valor do
máximo variable amount ou seja se o
usuário setou esse valor ele setou um
valor máximo do pagamento eh eu posso
diminuir ou aumentar pela iniciadora só
que se eu não setei isso e eu quiser
definir o valor isso só pode ser feito
direto na detentora né então se eu não
setei o Max bovar amount né e eu tentar
fazer essa essa setar isso na iniciadora
isso tem que retornar um erro né mas
acho que acho que nesse sentido acho que
a orientação vem nessa página de
auxiliar aqui né que tá descrito aqui o
que que pode ser feito em cada lugar
exemplo esse tipo de coisa né mas acho
que para critério do teste o importante
é ter essa esse teste aqui vai ficar
esperando 10 minutos né E aí nesses 10
minutos vai ficar fazendo um pulling né
E aí você tem que ir pela sua interface
né na teoria ali fazer a alteração
desses valores que estão sendo
solicitados aqui e aí tá tudo descrito
aqui né na parte de cima do teste o que
que precisa ser alterado faz essa
alteração e o teste vai continuar com
sucesso eh e aí na sequência um teste de
edição negativo né Então essas questões
do que não pode editar do que pode
editar Aonde isso tá sendo testado e um
teste também né então muito importante
ver aquela página lá entender o que pode
ser alterado no iniciador o que pode ser
alterado no detentor o que não pode ser
alterado e enfim e conseguir bater isso
aqui e tem um teste para fazer essa
verificação também
Eh esses dois a gente já falou isso aqui
são os testes retra que vou falar na
sequência
Eh aí tem um teste time Zone né que é só
um teste enfim agendamento de um
pagamento desse first payment né do
primeiro pagamento eh entre 9 e 23 e aí
o último é a parte de web Hook como eu
comentei né a gente verificar se o
Estados de pagamento agendado emite uma
notificação de webook Então os planos
digamos assim né padrões Acho que são
coisas muito parecidas com que a gente
feit Eh agora eu queria só explicar um
pouquinho sobre os testes de retra né
então a gente tem essa nova
eh essa nova capacidade dentro da pei né
que são tentativas intradia e Extra diia
eh tem uma série de complexidades
digamos assim dentro disso né porque
enfim são pontos que vão exigir enfim
inclusive interações entre múltiplos
Dias gestão de todo esse caminho né e a
gente teve várias discussões com relação
à melhor maneira de fazer esse processo
de testagem né porque acho uma das
características é que se eu tenho que
esperar um pagamento falhar para eu
testar o retr significa que um teste vai
ter que demorar de 2 a 10 dias né então
a gente começa a introduzir
complexidades dentro do processo de
teste né E aí a gente chegou numa
conclusão aqui do que seria útil e
melhor testar né aí eu vou começar pela
imagem aqui embaixo na verdade eu tô com
ela até aberto aqui só para mostrar para
fazer um um retry né para fazer essa
retent ativa a gente tem inicialmente o
agendamento do pagamento de 2 a 10 dias
a gente tem uma falha no no pagamento né
E essa falha no pagamento tem que ser
uma retornar um erro que quem o end ID
para eu Enfim fazer aquela R tentativa
env no end ID de novo ou não eh a
depender do que foi colocado ali e aí a
gente faz o retrai entre aia então aqui
Já demorou no mínimo dois dias sendo que
tem que ser atrelado a uma falha do
pagamento também que é algo que não se
controla dentro do teste na sequência
tem que ter a falha do pagamento e aí
sim tem a r tentativa extra dia o que
que a gente vai testar disso tudo a
gente não vai testar o fluxo end to end
como a gente geralmente faz o que vai
ser testado é mer ente o retrai né e é
esperado que todo esse processo aqui né
de agendamento do pagamento falha no
pagamento tudo isso seja feito através
de massa de dados a gente vai ter dois
planos auxiliares que eu vou mostrar já
que vão enfim orientar essa vão auxiliar
né se as instituições quiserem usar essa
criação da massa de dados mas é critério
da instituição usar enfim setar como
isso quer como quiser né um ponto bem
importante do ritra que também é é um
ponto acho que vai ser um Pain Point ali
durante o período certificação é que a
massa de dados ela queima né então o que
que isso significa uma vez que eu Rode o
teste se eu quiser rodar o teste de novo
eu vou ter que gerar uma nova massa de
dados setar um novo plano uma nova
configuração e rodar o teste de novo né
então é importante que esses testes de
TRS sejam feitos inicialmente porque o
ciclo de feedback não vai ser aquele
ciclo de feedback Onde eu posso fazer
alteração subir alteração clicar replay
Test e ficar clicando em replay
eternamente né eu preciso setar uma
massa de dados testar um pouco similar
ao que acontece Às vezes a gente tá
testes de qrcode dinâmico na v4 né Eu
acho que era um ponto de dor dentro do
processo de certificação então muita
atenção com relação a isso vou explicar
o teste aqui né mas acho que
é ponto principal é esses testes vão ser
mocados né mocados no sentido da massa
de dados a funcionalidade em si a gente
vai testar ela funcional só que a massa
de dados é esperado que seja entregue
pro Motor um cenário preparado para se
testar o r TR né e eu vou comentar sobre
o que que é isso eh enfim esse plano ele
tem quatro testes eh a gente tem as
tentativas intradia e as tentativas
extrad tem dois testes de intradia dois
testes de extrad em em cada cenário né
Um cenário feliz e um cenário infeliz
eh como eu comentei né os cenários
exigem massa de dados os testes vão
validar apenas as tentativas o setup vai
ser realizado antes da execução como eu
comentei e a gente vai ter um plano
auxiliar de para facilitar o setup da
massa de dados eu vou mostrar como é que
isso vai acontecer aqui então falando
sobre os testes de ritra né a gente tem
esses quatro testes todos eles têm ritra
no nome né então para quem que você
achar eh na verdade api intrad extrad né
então coloca extrad intrad vai ser
possível achar aqui ou filtra pelo plano
de teste né que no plano de teste tem o
nome do retra aqui eh então como eu
comentei né se a gente olhar aqui acho
que isso é bem similar para todos os
testes né é muito ler o Sumário né
quando a gente entrar no teste L aquela
parte que tá em cima lá do aquela parte
azul né do plano de testes do módulo tem
escrito lá exatamente a descrição do que
é esperado dessa dessa massa de dados e
a gente olhando aqui né a gente vai
esperar um um consente ID pré-criado
então o o consentimento já tem que estar
criado e por que que o consentimento já
tem que estar criado porque eu já
preciso ter um pagamento que falhou
debaixo daquele conente ID Então a gente
vai ter apresentar um conente ID já
criado que vai ser preenchido na
configuração do teste e vai precisar do
refresh Token né porque o refresh token
vai ser gerado no redirecionamento no
momento da e do redirecionamento do
usuário né então se a gente quer um
consentimento que já tem um pagamento
que falhou significa que o refresh token
já foi gerado então a gente não consegue
só com conciente ID dar sequência no
teste né Então as informações que a
gente vai precisar é qual que é o
consciente id e qual que é o refresh
token né que vai ser utilizado E aí
obviamente que esse refresh toking tá
tem que estar ligado com os eh com os
certificados que estão sendo utilizados
na plataforma né esses testes aqui né
também né Por ter essa característica
são testes que não vão para FP né se a
gente quiser evoluir isso vai ter que
ser uma discussão à parte são testes que
vão ser testados em sandbox né E a gente
vai precisar do consente ID vai precisar
do refresh Token dos certificados Como
já é colocado lá né Eh Y
op Boa tarde deixando só uma dúvida se a
gente tiver um consentimento que for
criado na v1 Teria algum
problema os testes se a gente
utilizasse Enfim acho vai depender muito
até de uma política enfim não sei se
isso foi discutido no GT já mas é um bom
ponto porque o que a gente vai fazer
quando se o consentimento foi criado na
v1 a gente vai pegar o consciente que
você colocou e vai chamar na V2 Então se
essas apis tiverem funcionando O que foi
queda da na v1 consegue ser consultado
na V2 acho que na Perspectiva do teste
vai funcionar Mas é uma enfim até uma
dúvida aqui que eu vou deixar enfim
depois eu deixo o pessoal do GT aqui
pessoal do GT al responder não sei se
isso chegou a ser discutido se vai ter
período de convivência alguma coisa
nesse sentido né mas
eh na Perspectiva do teste O teste vai
pegar o constante que você passou na
configuração e vai chamar o endp de V2
né pro teste o v1 não existe ele vai
chamar de V2 Se eu conseguir o processo
de criação né a gente não tem como
controlar e nem vai controlar isso então
se você criou pela v1 enfim dado a sua
estrutura interna fazer mais sentido se
eu puder consultar isso na V2 O teste
vai funcionar
entendido Obrigado nada e aí falando da
estrutura do teste rapidamente né a
gente tá até um pouco passando da hora
aqui mas falando da estrutura do teste o
que a gente vai começar né a gente
começa o teste fazendo a verificação
dessa massa de dados então a gente dá um
get Verifica a massa de dados e depois a
gente começa a estrutura do retri né e
Ou seja eu vou verificar se se a gente
se eu citei corretamente né importante
também notar que quando eu setar essa
massa de dados né a gente tá usando um
caso que queima entend ID então quando
eu olhar para essa tabela aqui né é
importante que eu sete essa massa de
dados com um erro que exige o reenvio de
entend né então um desses cinco
primeiros aqui eh acho que prestar
bastante atenção nisso né Isso vai est
descrito no teste também dependendo de
como você tá mas eh
enfim e aí na sequência a gente faz o
pagamento utilizando aqueles Campos que
o que o José comentou né do original rec
payit id e espera que eu consiga agendar
esse pagamento né que é uma
característica específica porque essa
tentativa intradia acho que é o único
caso onde eu vou agendar um pagamento
pro mesmo dia né então faço um post
payments com a data de hoje isso esse
pagamento tem que ser agendado porque
tem aquela janela de liquidação né então
ela não vai ser liquidada de imediato
então bem importante isso aqui tá bem
implementado enfim esses mecanismos de
controle como a gente comentou né Essas
regras de validação do payload a
depender do que tá sendo feito se tá
sendo feito um primeiro pagamento se tá
sendo feito um pagamento da recorrência
ou se está sendo feito um pagamento um
retri né a depender do que for feito as
regras são diferentes né então bem
importante isso eh na sequência a gente
tem um pagamento intradia massa de dados
é muito similar né mas aqui a gente tá
simulando um pagamento intradia sem
sucesso acho que um ponto importante
também né acho que eu não preciso Jé
comentou né mas a gente tem aquele Campo
que é o iG try accepted esse campo eh
ele só vale para tentativas extra dia né
porque pro usuário pagamento tem que
acontecer naquele dia Independente de
quantas tentativas forem feitas né então
a gente inclusive pede que o e TR
accepted PR os pagamentos intra dia PR
os testes intra dia sejam como falso né
Para justamente deixar claro para todo
mundo que esse campo se refere a
tentativas extra dia eh então enfim aqui
a gente vai fazer um pagamento fora do
prazo então de alguma maneira é um teste
de time Zone já que tem que ser feito
depois de meio dia
eh e enfim a gente espera para aquele
fora do prazo permitido né então
importante se atentar também aquelas
janelas né de quando pode ser feito o
retri quando não pode toda essa regra
essa lógica condicional de validação do
Pay Lob né prestar bastante atenção com
relação a isso
eh na sequência a gente tem o Extra dia
né E aí o Extra dia a gente tem um
pagamento com sucesso setar massa de
dados é muito similar a diferença é que
para pagamento int dia a gente vai
precisar de um pagamento sem sucesso né
que é o pagamento que a gente tá
querendo fazer para o teste extra dia a
gente vai precisar de dois pagamentos
sem sucesso porque é o pagamento em si e
a primeira tentativa extrad que deu
errado e a primeira tentativa intradia
que deu errado a gente segue pr pra
tentativa extra dia então tem uma
diferença de massa de dados entre os
testes né um vai exigir um pagamento e
outro vai exigir dois pagamentos
falhados enfim respeitando as regr de
negócio
eh e por último a gente tem um um
cenário infeliz de pagamento Extra diia
agora sim né onde a gente tem o wiit TR
accepted como falso e a gente espera que
esse pagamento não eu não consiga fazer
esse pagamento Extra de né dado que o
usuário não consentiu comr tentativas
extra dia
eh Então essa a estrutura dos Testes de
retry né A minha sugestão né Dá uma
olhada no plano dá uma olhada no teste
eu vi que tem um pessoal que tá mandando
ticket no service desk já que a gente
vai responder com dúvidas e é um teste
diferente esses testes trai então
qualquer dúvida né se ano a gente ver
service des a gente vai est lá mais que
disponível para poder auxiliar todo
mundo a execução dos Testes né Eh acho
que um ponto importante também o mabank
vai suportar como a gente já faz né hoje
a gente tá nesse processo como eu
comentei né da Beta 1 com a beta2 Então
e o mock Bank já tá ajustado para beta2
e o motor a gente só tá com o plano da
Beta 1
deploiement foi executar agora o plano
do motor contra o mock Bank pode pegar
algumas Desc panças Nesse sentido porque
eu só tem o plano da Beta 1 e o m já tá
na beta 2 que é a a a especificação
vigente lá dentro do portal Mas enfim
acho que já é um ponto onde se pode
interagir com isso e o ma vai est
disponível então se tiver dúvida como
teste funciona é muito recomendado
utilizar o mooc se tiver dúvida como
utiliz o mock para isso também a gente
vai ter a documentação documentação não
tá clara abck service des pra gente
poder até esclarecer a documentação se o
caso ou enfim ajudar nesse sentido e por
último falando bem rápido aqui né os T
de retri que a gente comentou vai ser um
plano a parte que vai ser criado junto
vai tá disponível também para todo mundo
e basicamente vai ser um plano bem
moldável né O que que é um plano bem
moldável eh a gente vai ter um plano com
dois módulos você vai conseguir
configurar como que esse pagamento vai
ser feito eh dentro da configuração
Então qual é o amount Quais são as
informações de crédito quais são outras
informações né E que vai ser o start de
time expiration de time accepted tudo
definido na configuração do teste então
na configuração do teste você define
como você quer fazer o pagamento Qual é
a data que você quer fazer o pagamento e
ele vai simplesmente fazer esse
pagamento e não vai verificar se o
pagamento foi aceito enfim a a intenção
é só fazer o pagamento né Aí como cada
pessoa né vai ser tách que a gente não
pode definir né nem vai definir como
cada um vai setar Mas enfim são planos
para auxiliar né então Se alguém quiser
fazer um sistema de Trigger para
conseguir setar essa massa de dados de
maneira mais fácil enfim cada
instituição vai definir né o que que
quer fazer né para setar essa massa de
dados ou se faz na mão direta no banco
você cria uma automação por fora enfim
eh a critério de cada um eu acho que é
só que esses dois módulos estão aqui
para modos onde você pode fazer um
pagamento do jeito que você quiser né E
e aí um teste faz um pagamento Outro
teste faz os pagamentos justamente pela
diferença de testes intradia extr diia e
cada pessoa ali enfim seta da maneira
que quiser não é obrigatório utilizar né
como eu falei eh a intenção é só gerar
um jeito mais fácil de ajudar todo mundo
a criar essa massa de dados aí no final
ela loga ali o conente AD permite AD o
refresh token para você já pegar copiar
colar no plano e rodar o plano de retra
eh em resumo né acho que era só isso
tudo como eu comentei são muitas coisas
para serem testadas eh a gente tem três
planos de swiping account V2 a gente tem
quatro planos de pix automático um dos
planos a retra e a gente tá no final do
ano né então a gente já tá com o plano
já tem um plano de da Beta 1 lançado a
gente vai lançar já tem o Marco de 50%
na sequência acho que o Iago vai falar
um pouco mais disso mas acho que o
importante é muita atenção com relação a
tudo que vai ser exigido ao que tem que
ser feito qualquer dúvida a gente fica à
disposição BC Desk enfim se quiser
colocar aqui no chat também se tem
alguma dúvida já por hora eu tentando
responder
eh e é isso Paulo então devolver pro
Iago
a a dúvida era era para você mesmo
Cristian boa tarde a todo mundo boa
tarde quando você comentou sobre ainda o
primeiro plano eh do do teste de apoio
de retry né então acho que ele era
intrad você comentou sobre o status ké
que o pagamento deveria atingir eh nesse
momento por conta do mesmo que ele fosse
agendado pro mesmo dia por conta do
intervalo de tempo e eu perdi uma parte
acredito da explicação eh essa
informação ela vai tá contida no
pagamento ou no consentimento
eu não sei se eu se eu entendi legal
sobre essa questão do do intervalo de
tempo boa esse ponto em específico que
eu falei né porque a gente tem um caso
onde um pagamento feito pro mesmo dia
vai ser agendado esse caso é um retra
intra dia porque dentro do retra intra
dia né eu vou ter as janelas de execução
né então como o José falou ali eu tenho
até quando eu posso até quando vai ser
tentar vai vai ser a tentativa de ser
feita a primeira liquidação quando que
eu vou poder mandar uma nova tentativa
de liquidação entrad Quando que a
instituição Quando que a detentora né
vai tentar fazer o segunda tentativa de
pagamento então ainda que eu mande no
mesmo dia o pagamento não vai ser feito
imediatamente ele vai ficar agendado
para ser executado no mesmo dia mas na
janela prevista para ele né Então sempre
que for um pagamento ritr entra dia vai
ser um pagamento que vai ser feito no
mesmo dia então vou fazer um pagamento
hoje para a data de hoje e ele não vai
ter que ser liquidado né ele vai ter que
ser agendado para ser executado na Enfim
no no tempo previsto né na na janela
prevista E aí enfim como payload né como
você vai fazer essa gestão acho que é
muito dependente da arquitetura né mas
falando com relação ao payload a gente
tem aquele Campo que é o original
payment Original rec payment Se não me
engano né que é é o o lugar do payload
que mostra vou puxar sua tela de novo
rapidinho um segundo só para mostrar
esse
campo a gente tem esse campo aqui dentro
do payload que é o original recr Pay ID
ou seja se esse campo foi enviado
significa que é um retry então Enfim
pode ser um Trigger para disparar essa
validação de de de payload né então se
tem isso aqui eu vou mudar um pouco e
fazer uma validação de pagamento de
retry né
Eh mas acho que não sei se responde
exatamente a dúvida acho que o ponto
principal é isso tem essas digamos assim
né regras de validação de payload cond
acho ficou mais claro até porque para
ser condicional a parte que você falou
sobre preencher o payload Então a gente
tem que se atentar na hora de rodar
então o teste de retr ele não vai est
muito próximo à janela de execução
porque senão Talvez o pagamento iria
direto para quase que liquidado né exato
exato tem alguns testes Dead eles tem um
horário que tem que ser executado então
um é até meio-dia outro é depois de
meio-dia tá descrito lá também então é
importante ler com atenção a parte de
cima né primeira parte lá geralmente
essa parte de horário tá bem no começo
lá né falando esse teste tem que ser
executado até meio-dia esse teste tem
que ser executado depois de meio-dia
justamente para possibilitar esses
cenários né e acabar com uma validação
de payload condicional para intradia
entrar numa eh enfim num pagamento
imediato por exemplo perfeito Muito
obrigado nada
eí que é isso pessoal eh passa um
pouquinho da hora peo desculpa aqui né
mas de volta para você boa obrigado aí
Cris acho que pessoal agora entrando na
última parte aqui do workshop P que não
vai demorar muito também então já
falamos um pouco sobre
a o produto na parte funcional parte
técnica falamos da experiência do
usuário falamos agora com Cristian por
último relacionado aos testes do motor
de conformidade aqui essa última parte a
gente vai falar um pouco beleza
entendemos tudo isso Mas quais são de
fato agora na prática as
responsabilidades das instituições tanto
das detentoras quanto das iniciadoras
então aqui até por conta do tempo que já
passamos um pouco eu vou ser um pouco
mais objetivo aqui então
de então com relação a ao ciclo de
implementação dos apis eles são
divididos em quatro partes né então
podemos falar a concepção maturidade do
produto a certificação e a implementação
que é o piloto e o go Live então com
relação a essa api nós já passamos da
parte de concepção já foi lançada a
Betão dessa dessa dessa api já foi
implementado o motor de teste já foi
desenvolvida as p já foi divulgado
Inclusive a beta2 que estamos agora
nesse ciclo de maturidade então aqui o
ponto principal é a gente precisa muito
de feedback das instituições precisamos
que vocês já comecem a desenvolver com
base nessa especificação que nos deem
feedback seja via service desk testem o
motor também abram isos no gitlab aqui é
uma parte muito Interativa de evolução
da pi evolução do motor de testes pra
gente chegar no final chegar nessa parte
de certificação com uma versão estável
dessa pi eh sem problemas de
interoperabilidade no futuro Então esse
é o grande objetivo nosso nesse ciclo de
maturidade até chegarmos com motor de
testes atualizar na na versão estável da
especificação então chegando com motor
de testes na versão a gente entra na
parte de certificação que seria H
eventualmente podemos cobrar um uma nova
execução desse motor com a versão
estável podemos ter quebra de contrato
ali uma passagem para versão estável
Então pode acontecer isso então depois
que tem que vocês vão ter sucesso em
todos os planos de testes o processo vai
seguir exatamente como das outras apis
das certificações então abertura de
Ticket via service desk inclusão dos
planos de teste com sucesso nesse ticket
do service desk em seguida a gente vai
processar essa pedido de certificação
vamos enviar um link para vocês e pro
piloto seria colocar essa publicação das
apis no diretório de produção então e de
modo geral um pouco mais objetivo e é
isso que vai acontecer daqui pra frente
por enquanto por H estamos nessa etapa
aqui amarela que é a etapa de maturidade
da pi lançamos agora beta 2
eventualmente vamos ter no futuro também
a release candidate e a versão estável
da especificação e também do motor então
dando prosseguimento aqui também eh
respondendo perguntas relevantes que
para entendimento das obrigat das
responsabilidades que das instituições
então Ness C clo de maturidade só
retomando o que eu falei o ponto
principal é nosso grande objetivo é
chegar numa especificação e o motor de
testes maduro suficiente para não ter
problema de ter operabilidade no futuro
e o nosso a gente é muito dependente das
instituições de darem feedback fazerem
sugestões de melhoria comentar os pontos
de Dores estão sentindo tanto n
especificações quanto no motor de teste
seja via service desk ou gitlab para pra
gente fazer essas melhorias e chegarmos
num versio stavel sem sem nenhum
problema então paraa segunda pergunta
então quais são o que são exatamente
esses Marcos de certificação eu vou
entrar um pouco mais no detalhe para
frente mas nada mais são do que datas
que a gente estipule que as instituições
tenham passado em uma certa quantidade
de testes Então a gente vai ter por
exemplo em 14 deu um Marco de 50% As
instituições para garantir que elas já
estão começando a desenvolver já estamos
recebendo feedback das
instituições então entendemos que a a
versão atual das especificações As
instituições estão conseguindo passar no
motor Então são datas pra gente
controlar também esse desenvolvimento
das instituições e a gente ter um
feedback um pouco mais reativo do pro
nosso lado então como como vai ser essa
certificação então o processo vai ser
exatamente o mesmo igual comentei
abertura deic service desk enviar os
planos de teste com sucesso pra gente
então a automação vai gerar um link de
certificação e a publicação vai ter que
acontecer depois então respondendo as
duas últimas perguntas de uma vez com
relação ao piloto e a Live ainda estão
pendentes discussões e eh publicações
para vocês como vão ser exatamente essas
regras mas a gente já pode dizer que as
publicações dos apis vai ser pro pro
piloto então a certificação vocês vão
receber um link de certificação o piloto
vai ser vai ter um período de
convivência entre a V1 e a V2 e tem que
ser adicionada uma nova versão no
diretório dos participantes e não
alterado Para justamente o piloto ele
prosseguir na V2 dessa api então Além
disso pelot também além da publicação da
api a gente espera que as instituições
também tenham as ferramentas muito bem
eh configuradas lado como reportes para
PCM também vamos executar testes da fvp
contra as instituições E além disso
algumas outras regras que ainda vão ser
definidas vão ser compartilhadas com as
instituições tanto com relação ao piloto
quanto com relação ao go Live então
dando continuidade aqui falando mais
sobre o calendário vou primeiro falar
sobre as responsabilidades das
detentoras então a gente pode dizer que
tem quatro grandes datas a serem
eh terem um olhar um pouco mais atentos
para as detentores a primeira vai ser em
14 do1 que vai ser o Marco de 50% dessa
pi então dando um pouco de contexto a
gente Já publicou no início desse mês a
beta2 das especificações dessa api o
motor de conformidade ele vai ser
atualizado no dia 2 de Janeiro e no dia
14 a gente vai ter um Marco de 50% da
dessa api então para piques automático
tem um detalhe aqui do lado com relação
aos testes são 32 testes obrigatórios
para piques automático ou seja pro Marco
de 50% As instituições precisam passar
em 16 testes Obrigatoriamente sendo que
desse
16 dois tem que ser aqueles relacionados
com relação ao retry então a gente
divulgou o nome desses testes que
Obrigatoriamente tem que estar com
sucesso para Marco de 50% via informe e
para transferências inteligentes também
temos Marco de 50% na mesma data Então
são 18 testes obrigatórios paraas
transferências inteligentes ou seja nove
nove testes tem que estar com sucesso no
Marco de 50% com ponto de atenção aqui
que a depend da da oferta das
instituições pode ter mais testes
obrigatórios então por exemplo a gente
tem dois testes relacionado a
instituições que podem ofertar múltiplas
alçadas que devem passar nesses dois
testes e um teste relacionado a apj que
dependendo da oferta da instituição se
suporta esses produtos PJ também vai
aumentar a quantidade de testes
obrigatórios então esses são os pontos
de atenção para cada api tem Último
Ponto de atenção para esse Marco de 50%
também é que nem a gente também já
divulgou de for mais um ponto relevante
para essa atualização do motor que vai
acontecer em do de Janeiro para beta2 a
gente vai ter alteração relevante em
todos os testes ou seja se uma
instituição ela obteve sucesso nos
testes do motor antes dessa data de 2 de
Janeiro a partir da data da atualização
do motor a instituição vai ter que re
executar esse Test para ter sucesso para
ele ser contabilizado nesse Marco de 50%
então isso acontece porque por causa das
alterações que a gente teve nas
especificações da beta1 para beta2
alguns o sucesso no nos testes na versão
do motor na Beta 1 não necessariamente
garantem o sucesso no motor com
relacionado a beta2 então é por isso que
a partir de 2 de janeiro que vai ser
quando a gente vai lançar o motor na
beta2 As instituições precisam obter
novos sucessos para eles que sejam
contabilizados nesse Marco de 50% então
segunda data aqui que as entras têm que
ficar de olho é a data de 13 de Março
que é o Marco de 100% Ou seja todos os
testes eles têm que ser terem passado
com sucesso paraa garantia da do Sucesso
nesse Marco de de 100% E H depois disso
a gente tem a etapa de submissão e
certificação e a publicação no diretório
então aqui em 7 7 de Abril a gente vai
já vai ter o motor atualizado na versão
estável da api então
ah a gente pode solicitar também
dependendo das alterações que vão entrar
nessa versão estável uma nova execução
desses testes então ainda na certeza
quando tiver essas informações a gente
vai divulgar também só deixamos essa
linha aqui para deixar explícito que
pode ter essa possibilidade eigual
aconteceu com jornado s direcionamento
por exemplo que a gente pediu uma nova
um novo sucesso nos testes depois da
versão estável para submissão da
certificação então uma vez submetidos os
planos com sucesso no service desk a
automação vai pegar esses planos com
sucesso vai verificar Beleza tem todos
os planos com que nem deveriam ter a
partir das datas corretas a automação
vai gerar um link de certificação e até
21 de Abril As instituições vão ter que
ter publicado essa nova versão no
diretório em produção para a partir do
dia 22 vai ser de fato o início do
piloto que vai demorar vai durar até
16/06 que vai ser o go Live dessa ap
então aqui são as responsabilidades das
detentoras que eu comentei
e por último acho que é um diferencial
desse cronograma uma novidade que a
gente não teve nas outras certificações
é que a gente tem responsabilidades
também agora agora para as itps né Então
as iniciadoras Elas têm três Marcos para
serem cumpridos então
eh a partir de 29/04 as iniciadoras Elas
têm que ter pelo menos 10% das chamadas
dessa pii realizadas na nova versão a
partir de 20/05 um 50% a partir de 106 E
100% então esse novo conceito aqui da
para essas responsabilidade para essas
itps é justamente pra gente garantir que
o período de piloto ele tá sendo
transferido para uma nova versão de
forma gradual e pra gente evitar que a
as chamadas na nova versão sejam
aconteçam muito pro final do período de
piloto e a gente encontrar eventuais
problemas com uma certa antecedência do
golive então aqui eu fui um pouco
objetivo mas com entendo que eu falei
Unos pontos principais gostaria de falar
até por causa do tempo que a gente
passou um pouco então acho que só
gostaria passar algum alguns links úteis
aqui então reforçando a gente espera que
vocês já tenham visto a a nova versão da
beta2 que foi de já publicar no portal
desenvolvedor Esperamos que as
instituições já estejam implementando as
apis com base nessa nessa certificação
nessa especificação perdão então
esperamos os feedbacks via service desk
Esperamos que vocês acompanhem também
via via informe as novidades que a gente
a gente vai enviando e hã e a demais
acho que é isso acho que algumas
mensagens finais aqui também acho que
agradecer a participação aqui de todos
agradecer o pessoal que fez essa
apresentação acontecer esse workshop
acontecer e no final a gente vai
consolidar todas as perguntas aqui Teve
muitas perguntas aqui no chat Imagino
que a gente não conseguiu responder
todas a gente vai pegar esse material
vamos vamos compartilhar com a com as
dúvidas de vocês essa esse workshop
também foi gravado a gente vai publicar
no canal do YouTube do Open finance
Brasil e acho que demais é apenas
agradecer a participação de todos
Esperamos que tenham tenha sido
discussões muito rías então muita
informação mas informações necessárias
aqui para para fazer essa certificação
acontecer e fazer ela dar
certo demais muito obrigado a
todos n