Workshop de lançamento de Pagamentos Recorrentes (v4.0.0 da API de Pagamentos)

pessoal acho que aqui a gente pode ir
começando Então bom dia a todos Obrigada
pela presença Eh meu nome é Fabian faço
parte aqui da da Diretoria de tecnologia
aqui do Open finance como responsável
aqui de
conformidade só introduzindo aqui o o
tema para vocês a gente tem alguns
lanamentos previstos pro começo do ano
que vem um deles é o de pagamentos
recorrentes e a ideia é a gente criar
esse canal de comunicação no formato dos
workshops pra gente ter uma se aproximar
das instituições se aproximar das
equipes de desenvolvimento a gente
trazer alguns esclarecimentos desde o
comecinho aqui do processo eh de
desenvolvimento dos produtos lançamento
das apis eh para trazer buscar trazer
mais clareza do que que é esperado O que
que a gente tá que que vem de diferente
nessas novas apis nesses novos produtos
eh Então essa semana e na próxima a
gente vai ter uma sequência de workshops
Então esse é o primeiro para pagamentos
recorrentes Amanhã a gente vai ter o
dfap único
eh atualização ali do perfil de
segurança no final da semana sobre
pagamentos eh movimentações automáticas
e na semana que vem sobre lançamento de
API de dados abertos e sobre API de
conen resources e câmbio então muita
novidade acontecendo por aqui então
queria agradecer a presença de todos
vocês fiquem à vontade para compartilhar
o convite com as equipes e com quem
vocês acharem necessário E aí pra gente
começar aqui no no tema de hoje
pagamentos recorrentes a gente vai tem
alguns apresentadores Então a gente tem
o Wendel aqui que é o PM responsável
pela parte da especificação da api aqui
de do produto aqui de pagamentos a gente
tem o José Henrique o Zé que é o o nosso
api Expert o Gustavo bresler que é
membro aqui do GTI para falar um pouco
sobre como vai ser a experiência do
usuário o Cristian para falar sobre a
parte de testes e eu vou voltar aqui no
finalzinho para falar um pouco sobre o
que que é esperado das instituições
Quais são os próximos passos cronograma
como que vai ser como que vão ser esses
próximos meses e as interações previstas
tá
eh aí aqui só pedindo para vocês podem
mandar dúvidas no chat a qualquer
momento aí a gente vai ter um momento
para dúvidas no final então passando já
aqui pela agenda eh Então idealmente a
gente vai responder todo mundo no
finalzinho
e enfim aí aqui é é ser produtivo para
todo mundo tá então obrigada então pra
gente começar então A ideia é a gente
passar pelo o que vai ser pagamentos
recorrentes o que que é esse novo
produto que tá sendo lançado entrar no
detalhe da especificação do sweger o que
que vem de diferente Nessa api depois o
que que vem de diferente na jornada o
que vai ser testado e o que vai ser o
que tá sendo esperado tá
então Começando aqui então passo a
palavra aqui pro meu caro Wendel Então
bom dia bom dia a todos Obrigado Fabi
eh a ideia aqui né como a Fabi comentou
turma é falar um pouco sobre o que que é
pagamento recorrente né então a gente
vai passar para por esses tópicos aqui
então o que que é o pagamento recorrente
O que está sendo lançado por que que
essa feature surgiu Qual o problema ela
soluciona as principais funcionalidades
e quem é obrigado oferecer o produto né
então assim antes mesmo da gente começar
aqui o workshop a ideia eh dar um um só
fazer aqui um parênteses que seesse
workshop ele não tem a pretensão em
passar em nenhum ponto sobre a estrutura
do piit Tá mesmo que a gente saiba que
existem ali algumas interseções a ideia
não é falar sobre o o piit
eh e aí assim né o objetivo é falar
sobre a motivação que a gente teve aqui
para fazer a construção né os casos de
uso a jornada de Rex e o que que é
esperado como a Fabi comentou e antes de
começar aqui a apresentação eu quero já
deixar eh um agradecimento especial aqui
pro para toda a estrutura da camada
administrativa aqui o secretariado
seleme Laí a coordenação decampo Fábio
As instituições participantes aqui do GT
e ao time de produtos que no final a
gente vem trabalhando sempre numa
parceria com todas as com todos aqui que
eu comentei de forma a garantir uma
melhor entrega do do do das nossas
especificações então só para deixar
registrado Quero agradecer o apoio do
Edson que é o nosso q eh o Henrique que
é a parte de agilista E o Zé que entra
aqui como a parte de arquitetura tá
então dado todo esse esses pontos aqui
eh que que é o pagamento recorrente né
turma eu acho que a pra gente poder
começar aqui é
é explicar realmente o que que é então
pagamento recorrente ele possibilita
agendamento de vários pagamentos
partindo de um usuário pagador
para um recebedor esse pagamento ele
possui valores fixos que podem ser
programados conforme a preferência ali
né Eh eh do do usuário Então ela pode
ser tanto mensal semanal diária ou até
mesmo em datas customizadas então assim
aqui é um overview mais da parte de
negócio para vocês entenderem o
comportamento aqui da eh O que que é
esperado dentro da da das especificações
E aí mais para frente a gente vai
descendo um pouco mais no nível também
falando ali sobre os os principais
tópicos que foram construídos ali dentro
do slager né então o que que tá sendo
lançado tá sendo lançado a
funcionalidade de agendamento recorrente
onde através do mesmo consentimento é
possível realizar múltiplos pagamentos
para o mesmo recebedor então assim o
principal ponto aqui dessa ap da AP de
pagamentos na sua versão 4 é o
agendamento recorrente então todas as
funcionalidades que existem na V3 de
pagamento instantâneo agendamento
permanecem o que a gente tá ampliando
aqui é colocando mais esse essa
possibilidade de utilizar ali o
agendamento recorrente eh mais paraa
frente tá então por que que ela surgiu
né então assim ela surgiu no final para
poder embarcar
eh o ela surgiu devido à evolução aqui
do pix né na construção do seu canal
secundário mas eu acho que o principal
ponto aqui turma não é falar do pix né
como como eu comentei e eh ela surgiu
mesmo devido a evolução do ecossistemas
e dos meios de pagamento né então eh a
funcionalidade ela permite agendamentos
de múltiplos eh eh múltiplos recebedores
Tá qual que é o problema que que a essa
funcionalidade ela vem aqui para tentar
resolver né ou ajudar a criar habilitar
novos casos de uso Então ela é Ela é
útil né tanto para os consumidores
individuais quanto para empresas que
elas visam atender as
cidades doss casos ali que que são
esperados dentro do do ecossistema Então
quais são aqui a gente trouxe aqui
alguns exemplos foram até alguns pontos
que dentro da da nossa etapa aqui de de
especificação a gente o banco central
num papel aqui muito importante trouxe
ali algumas
eh algumas sugestões mas a ideia que não
é só ficar nesses Nesse contexto é é
poder expandir isso aqui eh mais né
Então quais são os casos de uso então a
mesada ali né então onde eu o o pai que
quer fazer um pagamento específico para
um filho para alguma questão fazer ali
Toda Toda vez um um agendamento né
pagando ali pro para para essa pessoa
questões de doação então pagamentos de
serviços diversos então tem a gente
pensou aqui em casos de uso como eh
pagamento da de uma diarista professores
particulares pagamento de psicólogo
então assim Existem várias
possibilidades aqui paraa gente a gente
poder eh trabalhar né E aí é esperado
mais casos de uso eh de todas as
instituições então legal qual que é a
principal funcionalidade aqui né Eh a
principal funcionalidade é o agendamento
de múltiplos pagamentos fixo com duração
de 24 meses eh aonde o o recebedor
utiliza eh Onde é utilizado o mesmo
consentimento tá então a ideia aqui é
trazer esse overview aqui para vocês e
quem que é obrigado a oferecer esse
produto né então dentro das discussões
aqui e e como pra dentro do ecossistema
quem é obrigado a oferecer são os
detentores de conta e opcionalmente as
iniciadoras elas podem ofertar essa
solução ali pro paraas instituições pros
seus clientes também pode ir lá
Fabi aqui eu passo a palavra pro José
que é o arquiteto que vai dar aqui um
overview bem amplo sobre essa questão
das especificações desculpa
fa Bom dia pessoal
eh eu sou José Como and já falou
trabalho aqui na estrutura da dto al de
dentro do grupo técnico de pagamento né
do GT serviços eh eu vou passar aqui
agora pelas principais alterações que
nós
tivemos Tecnicamente falando dentro da
api né O que que nós precisamos alterar
e
porqu em alguns pontos de porquês também
tá
eh primeiro eu vou trazer o que que
mudou né assim digamos a no mais alto
nível
possível vocês podem ver que ali a gente
tem o tópico da máquina de Estado então
ocorreu a remoção do patc do pagamento o
que isso significa significa que a
partir de agora quem controla essa
agenda de múltipla alada é o
consentimento e pro consentimento poder
controlar essa essa agenda de múltiplas
alçadas a gente criou um status novo
dentro do consentimento que é o pasa de
accept tá então a partir do momento que
o primeiro
autorizador perfeito aqui então a partir
do momento que o primeiro autorizador eh
realizar autorização ali né do do
consentimento de múltiplas alçadas ele
vai continuar tendo seus 5 minutos para
realizar a primeira aprovação mas após
isso o consentimento vai paraaa deess
enquanto Aguarda a aprovação dos dos
demais aprovadores tá
e falando agora al sobre o o tópico do
validações no funil de consentimento
eh na V3 de pagamentos nós fizemos um
trabalho bem extenso de rejection
reasons para consentimento né a gente
trouxe vários motivos de rejeição pro
consentimento e a gente foi descobrindo
novos desafios né decorrente dessaa
decisão
eh e um desses desafios foi caso o
consentimento tenha mais de um motivo
para ser rejeitado né como que nós
tratar esses motivos de rejeição então
Nós criamos uma ordem de prioridade dos
motivos de rejeição que vão est
disponíveis agora a partir da v4 também
eh a geração do exap interaction id pelo
detentor vocês vão ver que nós
recentemente criamos um problema sido na
V3
que hoje com a PCM nós precisamos que
esse FX fap interaction ID ele
seja sempre devolvido em alguma das
pontas né então digamos assim se uma
instituição fizer uma chamada aqui eh se
um iniciador fizer uma chamada em um
detentor e esse detentor
não não conseguir atender por algum
motivo né caso tenha tido algum problema
na formatação por exemplo ele vai
devolver ver um parâmetro inválido ou
algo do tipo só que nessa devolução pode
dependendo do erro se for uma falha de
infraestrutura ou algo algo que não
permita que ele processe aquela
informação recebida ele não vai ter como
receber nenhum xap interaction ID Então
nesse caso ele precisa gerar um xap
interaction id e enviar pro detentor na
resposta de erro e o detentor vai
precisar catar Porque durante o momento
de reporte da PCM esses dados precisam
ser pareados
e essa é a maneira que a gente encontrou
de parear tá pode
Fabi agora a gente entra no produto no
novo produto em si
né Eh vocês vão perceber que tivemos
Novos Produtos novos objetos adicionados
na api né Nós temos ali dentro do
antigamente nós tínhamos o objeto
Schedule onde ele representava
apenas o o single né ele tinha somente o
o objeto single ali onde você fazia
agendamentos únicos
eh nós passamos a ter mais quatro
objetos eu acho que tá faltando um aí no
meio que é o monf que é o que representa
o mê tá
eh e o que que é isso né como que isso
vai funcionar na durante a criação do
consentimento Você vai precisar da mesma
forma que tinha um agendamento único
antes onde você passava a a data de
liquidação que aquele que aquele
pagamento ia ocorrer né hoje você vai
passar uma sequência de datas digamos
assim cada um desses objetos tem uma
quantidade
e a quantity e o Não me recordo preciso
abrir aqui só um minutinho
pessoal é o
o date né então a gente define uma data
Inicial que vai começar a funcionar e a
gente
define uma quantidade de recorrências
para que isso aconteça além de ter
algums outras características exclusivas
para cada um dos dos objetos né Por
exemplo dentro do objeto wik nós temos o
dia da semana e dentro do objeto MF nós
temos o dia do mês por exemplo por quê
Porque eu vou falar ali um pouquinho
abaixo sobre a a a janelas de tempo
fixas e móveis Tá mas
e é basicamente por isso nós definimos
ter janelas de tempos fixas aqui e não
janelas de tempos móveis Então a partir
da do momento que eu defino por exemplo
um agendamento toda quarta-feira ele vai
acontecer toda quarta-feira não vai
contar sete dias para acontecer ele foi
foi definido na quarta-feira então a
data fixa assim como o Day também e o o
monf também que a gente define lá todo
dia específico do mês para acontecer né
todo dia 25 de Janeiro por exemplo então
todos esses dias eles são datas fixas e
não você não conta 30 dias a partir da
data de criação por exemplo tá
eh com isso eu já falei ali do cálculo
das janelas de agendamento né janela
fixas versus as janelas móveis né a
gente não tem janela móvel aqui então a
gente não tem que se preocupar com
questão de quinto dia útil nem nada do
tipo
eh a responsabilidade dos papéis a gente
tem ali o iniciador responsável por
criar o consentimento como ele já mantém
hoje em dia né o funcionamento se mantém
do atual então o iniciador ele cria o
consentimento da mesma maneira que ele
já criava antes só que agora ele vai ter
que passar os parâmetros correspondent a
h h método de liquidação que ele vai
querer utilizar mais à frente né e o
detentor é o
responsável por realizar a liquidação
dessas solicitações de
pagamento como ele também é hoje se você
faz um agendamento único né como
iniciador o detentor passa a controlar a
agenda do pagamento a partir que ele dá
o aceite e você como iniciador precisa
ficar atento ao web Hook ou realizar o
pollin para poder recuperar as
informações
eh isso vai se permanecer para pro pra
v4 tá então se o detentor o iniciador
ele pode mandar 20 solicitações de
pagamento por exemplo a partir do
momento que o detentor dá um ok para ele
na requisição
é responsabilidade do detentor a
liquidação da agenda
tá a gente tem ali a atomicidade da api
né foi uma opção do grupo que não fosse
possível a realiza de processos parciais
né como assim
Eh hoje o pagamento na v4 ele estreou
recebendo uma lista
então você pode passar uma lista de n
pagamentos de acordo com o que você
definiu na criação do seu consentimento
tá
então o que isso significa significa que
Todas aquelas solcitações de pagamento
elas vão precisar ter seu status movido
né para agendar eh é mas se durante essa
tentativa de movimentação pro status de
agendado algum desses pagamentos não
forem possíveis alguma dessas
solicitações que foram recebidas na
lista não seja possível de ser movido
para scheduler por algum qualquer razão
que seja um Erro interno detentor uma
falha de
segurança alguma coisa assim eh todas as
solicitações de pagamento associada a
esse a esse que deu que falhou devem ser
canceladas tá
eh eh Isso é para garantir uma jornada
suave pro usuário a gente entende
que obrigar ele a refazer a jornada pode
ser um custo mas ter um serviço feito
pela
metade é um outro custo que eu acho que
a gente tem que testar o tradeoff
eh o sla para o envio dos múltiplos
pagamentos né Eh esse foi um ponto que a
gente discutiu bastante aqui dentro do
do GT e inclusive levamos para outros
GTS também porque a partir do momento
que nós podemos ter agendamentos de até
2 anos né que eh eu acho que eu não
passei por isso aqui mas uma mudança uma
mudança que teve bem importante foi
o o prazo máximo de agendamento né que
saiu de um ano e foi para dois então a
partir do momento que nós podemos ter
agendamentos diários de no máximo de até
do anos
Então imagina que como eu falei antes o
iniciador precisa mandar todas as
ocorrências de pagamento na chamada de
uma vez Então nós teríamos ali no
cenário mais agressivo digamos assim
730 solicitações de pagamento diário
sendo enviados de uma vez no no endp de
pagamento ali no post pi payment né
E nós estudamos se seria necessário um
ajuste de sla para esse endp visto que
agora pode ter bastante
casos né veio uma lista bem grande ali
de de
pagamentos desculpa eh levantamos essa
discussão com outros grupos e ficou
entendido que vamos continuar mantendo o
sla de 1 segundo e meio nesse primeira
nesse primeiro período e vamos estudar
caso detectamos que não tá sendo
suficiente caso tenhamos algumas
reclamações das instituições que não tá
sendo suficiente a gente internaliza e
melhora tá e a traz outra solução agora
falando um pouco do cancelamento dos
pagamentos a gente tem duas maneiras de
cancelar um pagamento nessa v4
eh a mesma dor que a gente apresenta
pela grande quantidade que a gente pode
apresentar para mover uma grande
quantidade de
pagamentos para agendado né a gente
também pode passar essa dor se a gente
precisar cancelar essa grande quantidade
de pagamentos né Eh no mesmo cenário que
eu falei antes a gente pode ter até 730
pagamentos diários por exemplo
eh o método de cancelamento desses
pagamentos na V3 que a gente tinha ele
era um pagamento por vez então
Eh para cancelar um cenário desse de
múltiplos pagamentos diários nós teremos
que chamar o Pat pix payment n vezes de
acordo com a quantidade de de
solicitações que a gente que nós
enviamos ali no momento da criação da do
pagamento né E para tratar isso Nós
criamos um endpoint novo dentro da v4
que ele vai receber o consent ID também
né Ele é um endp de cancelamento de
pagamentos tá mas ele recebe o consent e
o consent ID ali no seu pef
e com isso ele vai cancelar todos os
pagamentos que estejam agendados e
passíveis de cancelamento tá porque nós
também temos as regras de validação de
de de cancelamento de pagamentos né o
que que pode e o que que não pode ser
cancelado por exemplo um pagamento Ele
só pode ser cancelado hoje Se ele tiver
nos status pending E scheduled além
disso para ele poder ser cancelado tem
que ser feito até 24 horas até um dia
antes da data de liquidação tá não 24
horas você tem até as 23:59 do dia
anterior para poder fazer a solicitação
de um cancelamento de de pagamento que
vai ocorrer no próximo dia essas mesmas
regras se aplicam tá
eh falando agora da tentativa de
pagamento usando um consentimento em de
accepted quando eu tava falando ali da
máquina de estados eu falei que a partir
da o primeiro aprovador ele
precisa ser ele precisa aprovar em até 5
minutos né Então essa primeira aprovação
que ocorre o o o redirect pro iniciador
de volta né Pode ser que o iniciador ele
tente realizar uma chamada uma vez que
ele recebe algumas informações de acesso
já de segurança ele pode tentar realizar
alguma chamada com aquele consentimento
eh eh a gente entende que o
consentimento em si ele não tava pronto
ainda para uso né
então por causa disso Nós criamos uma
uma regra nova que caso o iniciador
utiliza um consentimento em accepted
para realizar uma liquidação esse
consentimento não vai ser cancelado nem
cons não vai ser rejeitado nem consumido
tá porque a gente entende que ele era um
consentimento que não tava pronto ainda
para ser usado
e não queremos que o usuário descarte a
jornada dele né Por se tratar de
múltiplas alçadas nós temos esse cenário
muito para para para PJ né
então seria um pouco mais Custoso Às
vezes você toda solicitação de pagamento
para um PJ e etc então
Eh optamos por manter o consentimento em
pxa de accepted temos um erro exclusivo
para isso dentro da api né que ele
informa Justamente que o pagamento que o
consentimento ainda tá em parte da seped
e não pode ser utilizado
tá e as datas inexistentes enviadas no
pagamento eh eu acho que eu já até vi
aqui que teve algumas perguntas sobre as
datas
eh
eh não pode ocorrer uma data inexistente
enviada no pagamento Tá pessoal se o
detentor receber uma data inexistente
ali dentro do pagamento ele vai rejeitar
a transação tá
eh basicamente o o iniciador precisa
traduzir pro cliente dele no momento de
criação do consentimento que aquela data
que ele selecionou não tem como
acontecer todo mê e e evitar que seja
enviado paraa frente pro detentor para
não dar uma frustração na jornada do
cliente tá ele achando que ele escolheu
as datas e tá tudo certo quando tenta
realizar o pagamento ele não consegue tá
então tem que ter um trabalho no
frontend do iniciador para evitar que o
cliente utilize sete essas datas
inexistentes para cobrança dos seus
agendamentos
tá eu acho que é isso Fabi falei
bastante
Zé muitíssima Obrigada eh pessoal tem
algumas dúvidas aqui a gente tá
consolidando então a gente passa por
elas no finalzinho agora queria passar a
palavra então aqui aspectos mais
técnicos como que vai ser o swager essa
parte aqui que o Zé acabou de explicar
Aí agora aproveitando esse ganch aqui no
final como que isso se reflete na
experiência do usuário aí eu passo a
palavra aqui pro
bresle Bom dia pessoal tudo bem colocar
a apresentação aqui para
vocês legal tá todo mundo
vendo confirm sim legal
eh então agradecer vocês aqui também
pela presença a gente foi um pouco menos
ortodoxo aqui quisemos trazer para vocês
As Visões de de ux tem um formato aqui
um pouco de diferente mas para facilitar
para vocês já verem como que vai
aparecer no guia como nosso Change log
aqui também eh a gente começa na parte
de experiência do usuário eh pela parte
da iniciadora onde vai feit vai ser
feita a solicitação da iniciação de
transação de pagamento eh a gente tem as
telinhas aqui mais para frente que
ajudam a ilustrar a forma como isso vai
ficar né na interface Mas passando aqui
pelos requisitos então eh no caso de
andamento recorrente a validade do
consentimento sempre vai ser até a data
do último pagamento limitado ao período
máximo de 2 anos eh sempre sujeito a
disponibilidade do saldo é uma
informação que tem que aparecer na
iniciadora que depois é uma recomendação
de que apareça na detentora também eh e
informar o cliente que no caso de data
inexistente como foi colocado eh
anteriormente o pagamento vai ser sempre
efetivado no dia posterior Então vamos
pensar aqui um dia dia 31 de Novembro
que a gente não vai ter a data seria
aqui e de pagamento no dia 1eo de
dezembro o que muda aqui eh com as
informações de requisito que são
mostradas na solicitação eh da iniciação
a gente tem o valor da transação de
pagamento do agendamento que é sempre um
valor fixo Eh vamos ter as informações
do recebedor com os dados referentes ali
ao recebedor o nome CPF mascarado e ou
CNPJ do recebedor e qualquer outra
informação eh que seja necessária aqui
com relação ao arranjo de pagamento
nesse caso aqui a gente tá trabalhando
com o pix pix o CPF do recebedor sempre
mascarado a gente tem a data do primeiro
pagamento a periodicidade da recorrência
pode ser diária semanal mensal anual ou
mesmo personalizada a gente vai entrar
nos detalhes aqui de como que essas
informações vão ser passadas da
iniciadora paraa recebedora também aqui
em seguida o número de recorrências
então o usuário pode escolher ali puxa
eu quero fazer 10 pagamentos mensais
então tem o número de recorrências ali
que foi o que limitou eh as próximas os
próximos agendamentos e a data do
encerramento do consentimento
Independente se ele el se ele fez Esse
agendamento por número de recorrências
ou por data ela aparece ali a data do
último pagamento e eh conforme o usuário
for eh escolhendo a sua periodicidade a
gente tem uma forma aqui de trabalhar a
periodicidade eh de forma a padronizar
para que todas as iniciadoras aqui
tragam a mesma mensagem e que possam
passar também paraa detentora essa
mensagem eh sempre igual quando for um
período personalizado então aqui no
período anual mensal semanal diário a
gente traz no guia eh eh o requisito
aqui de como trazer essas informações
para usuário então mensal duas recorren
duas ocorrências eh por eh até dia 18/1
eh de 2023 então a gente coloca aqui eh
duas frequências mensais eh e e a data
final também do último pagamento por um
exemplo e quando a gente vai falar de
pagamentos
personalizados que aqui a gente tem um
escopo muito grande de como pode ser eh
esse pagamento a gente trouxe aqui eh um
uma forma de ajudar a organizar pro
cliente vai ficar mais fácil quando a
gente mostrar ali na telinha também mas
por exemplo um usuário que vai
customizar aqui um semanal né Eh semanal
toda terça e quinta-feira duas vezes por
semana até o dia 30 31/12 perdão eh a
cada dois meses por exemplo o pagamento
bimestral em que a gente faz aqui eh até
a data especificada pelo usuário e aqui
a gente traz todas essas maneiras de
ajudar eh o usuário a entender depois na
tela da detentora também o como que ele
tá aprovando aquele consentimento sempre
trazendo esses requisitos aqui para
deixar claro para ele como que vai ser
feito esse tratamento personalizado
também das datas mas abrindo a
possibilidade para ele poder fazer aqui
agendamentos eh quinzenais por exemplo
ou agendamentos de mais um dia por
semana ou eh Dias específicos aqui
também nas telas aqui a gente já traz um
exemplo Inicial então o usuário pode ali
já de fato fazer um agendamento
recorrente mas ele pode também tá
fazendo uma uma transferência normal e
ter a opção ali de deixar essa
transferência como um agendamento
recorrente já tô fazendo uma
transferência tem uma opção ali de
agendar ela para datas posteriores então
aqui a gente tem eh essa opção aqui como
um Togo trazendo eh essa ilustração
também para todas as iniciadoras e a
gente traz aqui uma opção de eh seleção
do período de forma personalizada a
inspiração aqui foi fazer como a gente
faz eh em agendas digitais aqui que a
gente costuma usar bastante tem uma
interface bastante amigável então eu
consigo selecionar toda semana eu quero
agendar pagamentos terça e quinta por
exemplo para meu professor de inglês com
o número de 10 recorrências aqui eu vou
ter 10 aulas por exemplo e eu vou salvar
eh essa personalização aqui do meu
agendamento a gente tem ainda aqui na
iniciadora eh o resumo que que vai ser
que o usuário está querendo aprovar
então aqui a cada uma semana nas terças
e Quintas um total de 10 recorrências
pro usuário e os dados do recebedor e do
pagador e o valor fixo ali por ele
determinado
algumas recomendações então sempre na
iniciadora o usuário poder editar ali os
campos de forma facilitada já na tela de
de revisão e também eh como foi
comentado inicialmente na questão de de
recorrências de agendamentos diários em
que eh são muitos agendamentos a
iniciadora pode aqui eh limitar Eh
quantos agendamentos vão ser feitos
desde que informe esse limite pro
usuário a gente já indo aqui paraa parte
da detentora de conta para confirmar
esse pagamento a gente tem os mesmos
dados que vão ser necessários ali na
tela de confirmação daqueles que foram
exibidos na iniciadora então novamente o
valor das transações que é um valor fixo
eh o valor da tarifa da iniciação se
houver aqui é a única diferença que a
gente vai ter eh as informações do
recebedor com a identificação do
recebedor nome CPF mascarado ou CNPJ e
outras informações Aqui de acordo com
cada arranjo de pagamento que possa ser
disponibilizado aqui no agendamento
recorrente a data do primeiro pagamento
a periodicidade número de recorrências
caso ela tenha sido informado Ali pela
iniciadora e a data de encerramento que
pode ser a data do último pagamento ou a
data da última recorrência ali
também aqui um exemplo uma ilustração de
uma tela como ela poderia acontecer
então vou fazer uma doação todo mês eh
de R 250 para uma ONG com a data
Começando aqui no dia 1 1/08 de 2023 de
2024 e ela vai acontecer mensalmente
também com os dados do recebedor aqui
nome e CNPJ do recebedor e os dados do
agendamento quando que ele começa quando
que ele se encerra pode ter uma opção de
ter um nome da recorrência aqui também e
a fonte de pagamento que cada detentor
aqui usuário pode ter eventualmente mais
de uma conta corrente naquele mesmo
login naquela mesma autenticação da
detentora de conta e a forma de
pagamento também dispon
izada aqui um outro exemplo também em
que a frequência é personalizada a
frequência personalizada duas vezes na
semana terças e Quintas o primeiro o
primeiro pagamento acontecendo aqui na
data 1/08 e o número total de 10
pagamentos também a gente tem as
informações aqui de início e de
encerramento também eh da mesma maneira
no caso aqui um CPF um recebedor é um
CPF então CPF aparece mascarado também
pelas regras do arranjo
PX uma recomendação aqui também informar
o usuário que qualquer pagamento
agendado ele tá sujeito à
disponibilidade de saldo isso é um
requisito para a iniciadora e uma
recomendação para detentora de conta
também aqui já entrando no momento de
efetivação Da solicitação então quando o
usuário é feito callback ali ele volta
paraa iniciadora de pagamentos e a
iniciadora tem como recomendação
informar o cliente que ele pode qualquer
momento com antecedência mínima de um
dia cancelar eh todo o agrupamento de de
agendamentos ou individualmente uma
transação e ele pode fazer isso tanto na
iniciadora quanto na detentora informar
para ele também eh que
a a efetivação aqui diz respeito ao
agendamento da transação e não a
efetivação do pagamento em si dado que o
pagamento vai est sujeito ao saldo no
dia da ah do do agendamento específico e
que o usuário também pode cancelar ou
alterar Esse agendamento até
lá essas são as recomendações aqui na
volta e a gente tem aqui alguns
requisitos também paraa área de gestão
de pagamento do ambiente Open
finance na área de meus pagamentos então
o usuário eh ela sempre vai est
disponível para ah ã quando o usuário
tem a possibilidade de fazer o
agendamento Então ela passa a se tornar
obrigatória na iniciadora desde que o
usuário tenha a possibilidade de fazer o
agendamento e como é algo que aqui tá
para todas as detentoras de conta a
possibilidade de eu agendar um pagamento
naquela detentora ela também se faz
obrigatória
eh na iniciadora e na detentora o
usuário vai poder ali consultar todo o
histórico de consentimento desses
agendamentos incluindo eh transações que
estão ali aguardando uma aprovação
aguardando uma múltipla alçada que estão
estão agendadas que estão pendentes
concluídas canceladas todo esse
histórico vai poder ser consultado ali
também e e quando for cancelada que
tenha a data do cancelamento também
explícita ali na parte de gestão tanto
na na detentora quanto na iniciadora eh
vai ser mostrado o status atualizado do
pagamento é importante que esses status
sempre sejam o mesmo então a mesma
informação que o usuário vê na detentora
ele vai ver na iniciadora também pra
gente não ter aqui uma divergência de
informações e eh agendamentos
recorrentes que cuja conta do recebedor
eh for encerrada tiver ali alguma
questão que ela não puder ser efetivada
para aquela conta o usuário vai poder
ser informado ali também pela detentora
de conta que aquele pagamento como os
demais eh que estão previstos eles não
vão ser efetivados por aquela razão por
aquele motivo específico na iniciadora
de pagamento ele deve ter
disponibilizado ali uma opção para eh
alterar aquele agendamento cancela a ele
fazer um novo também eh adequando o
recebimento daquelas daqueles
agendamentos
também como recomendação eh a gente traz
aqui também Que Essa gestão de
pagamentos possa ser feita na área PX
nesse momento em que o arranjo pix eh é
o que tá dando suporte pro agendamento
recorrente de pagamentos no open finance
e recomenda também que as instituições
detentoras de contas da maneira que elas
já trabalham com seus usuários possam
ali avisar de maneira ativa ou passiva
da Necessidade do usu usuário ter saldo
para efetivar aquele pagamento que está
agendado a detentora de conta deve
apresentar também uma mensagem deve não
é uma recomendação que ela Apresente uma
mensagem que fique claro a condição para
o pagamento ser efetivado e o que que
acontece caso ele não esteja não tenha
saldo no momento de efetivação vai
entrar no cheque especial não vai entrar
no cheque especial como que ele já tá
acostumado a trabalhar com aquela
detentora de conta eh e para
agendamentos recorrentes também a gente
sugere que sejam utilizados recursos
para melhorar a organização e a
visualização de agendamentos recorrentes
pode ter um filtro pode ter uma busca
ordenação dos agrupamentos usuário pode
clicar num agendamento só e ver todos os
próximos agendamentos que estão ali eh
como lançamentos futuros então
disponibilizar pro usuário eh através de
elementos gráficos uma maneira melhor
dele conseguir ali gerenciar os seus
agendamentos futuros
também e isso vai de cada casa porque
cada casa ali vai ter o seu padrão eh e
a sua a a maneira de comunicar com o seu
cliente na parte de revogação o usuário
deve ser sempre capaz de revogar o
consentimento que ele deu para
agendamentos recorrentes tanto na
iniciadora quanto na detentora de contas
e e ele deve ser capaz de excluir tanto
um agendamento específico como todo o
grupo de agendamentos ali também para eh
que ele não tenha mais agendamentos
futuros Mas puxa tem um mês aqui que eu
tirei férias eu não vou ter a minha aula
de inglês eu consigo cancelar os
agendamentos específicos daquele mês ali
também para pagar eh o o objetivo do meu
do meu agendamento aqui também e assim
ter uma facilidade maior de alteração
dos seus agendamentos
também para agendamentos únicos e
recorrentes o usuário deve ser impedido
de revogar o consentimento até às 23:59
do dia anterior do próximo pagamento
agendado isso se dá também para que a
gente sempre tenha eh esse eh essa
repercussão do que foi feito na
detentora e na iniciadora esteja sempre
eh eh alinhado e que tenha tempo hábil
para ser feita essa comunicação dado que
a detentora aqui pode a partir da da
meia-noite aqui já efetuar o valor da
execução da liquidação daquele
agendamento
também e deve ficar claro sempre pro
usuário final que a revogação ela é
Irreversível a partir do momento que ele
cancelar uma ou outra uma ou todas as
recorrências daquele grupo que ele não
consegue mais eh incluir uma nova dentro
daquele grupo de agendamentos ele
precisaria fazer uma nova transferência
ou um novo grupo de agendamentos
também na parte de alterações é o mesmo
requisito que a gente tem aqui o usuário
pode pessoal eh brear eu parei de te
ouvir não sei se fui só eu não travou
para todo mundo L ficou mudo ficou mudo
mesmo você conseguiu Opa voltou aqui
caiu o meu fone obrigado então aqui é o
mesmo requisito então o usuário pode
alterar o consentimento até às 23:59 do
dia anterior dado que a partir da
meia-noite e um segundo aqui eh já pode
acontecer a liquidação daquele
agendamento na detentora
também estão me
ouvindo legal sim de
ouos e deve ficar claro também pro
usuário que qualquer tipo de alteração
assim como a revogação é Irreversível
ele vai ser redirecionado para detentor
de conta para confirmar aquela alteração
e ela vai ser eh
Irreversível e é isso pessoal isso era o
que a gente tinha aqui com relações a
interface Muitíssimo obrigada
eh passando aqui
paraa próxima etapa deixa eu aqui de
novo a tela passo a palavra aqui pro
Cristian que ele vai explicar um pouco
como que vai ser o que vai ser testado a
parte de motor de conformidade funcional
Então bom
dia bom dia bom dia pessoal como falou
me chamo Cristian trabalho na com
product Manager a gente junta a
estrutura Central aqui entrega o motor
funcional funcion aqui basicamente
dentro Brasil pass essa parte agora da
apresentação o Zé e o wend Eles já
facilitaram bastante o meu trabalho né
comentando ali sobre as especificações
sobre as mudanças e tudo mais
basicamente o que a gente vai fazer no
motora traduzir tudo que foi falado até
agora em cenários então eh uma
perspectiva mais prática ali né como
mortor funcionando e fazendo as chamadas
garantiam que todo mundo ali implementou
as especificações que a gente não tem
dúvida que todo mundo teve o mesmo
entendimento que não tem gaps nas
especificações então eh acho que todo
mundo já conhece ali o motor sabe um
pouco das funções dele né que a gente
vai falar agora aqui eu vou primeiro
aqui no slid né vou fazer uma uma
passada geral a gente não vai conseguir
infelizmente né fazer demo mostrar o
motor de fato funcionando etc mas por
conta do tempo e mas o motor já tá
disponível para faz TR v4 também né
desde o dia 24 é a gente vai então vou
fazer uma passada geral aqui depois eu
vou roubar a tela da Fabi rapidinho a
gente vai pro pro gitlab eu vou mostrar
lá um pouco documentação Quais são os
cenários de Fato e a gente vai ver que
basicamente vou estar repetindo muita
coisa que o Wender que o José falou aqui
Porque de fato e o que a gente faz
dentro do motor é pegar essa
especificação e transformar ela em
cenários práticos né pessoal eu acho que
tem alguém com o com o microfone aberto
não sei se se é só o meu áudio
aqui eu vou mutar todo mundo cris aí
você se desm
depois beleza
boá pode pode pegar a tela também tá
combinado então só começando aqui né
pessoal eh obrigado Fabi ão começando se
puder voltar na verdade Ach que eu i
passar pel primeiro depois eu ia
tranquilo tá voltando pera aí
beleza
foi foi obrigado é Então pessoal
Começando aqui pelo slide depois o roba
aqui a gente vai pro gitlab ali e o que
que vai ser testado aqui né dentro da
dentro da v4 a gente tem dentro a v4 a
gente tá falando de uma versão 4 né
então de fato é a gente já tem um
histórico ali tanto da especificação
então toda a lógica que tem que ser
passada da especificação quanto de teste
então cenários testados sempre que a
gente recebe uma nova versão de uma
especificação existente né a gente tem o
trabalho de primeiro entender quais os
módulos têm que ser replicados quais os
módulos têm que ser alterados e quais os
novos módulos que a gente tem que tem
que adicionar né então basicamente é por
isso que a gente tem um número bem alto
né Porque de fato é uma especificação
complexa que já tem um histórico ali de
amadurecimento eh de maturidade né
dentro do ecossistema então a gente tá
totalizando 64 testes aqui para API de
pagamentos esses 64 testes incluem
testes de web Hook incluem os testes de
pagamentos eh incluem os testes de eh de
pagamentos de agendamentos recorrentes
né E todos aqueles acho que muitos
cenários que a gente já conhece ali das
outras versões né e obviamente a quando
necessário eh aqui então para para v4 né
Eh a gente tem três testes eh três
planos de testes obrigatórios bem
similar ao que a gente teve na V3 a
gente tem um plano de teste padrão um
para kdn e um para time Zone né então
passando por cada um deles aqui o
primeiro que é o payment test plan v4 né
que é aquele padrão com maior número de
planos né esse é o plano digamos assim
né Como comentei padrão ele tem todos os
cenários ali positivos negativos AD
cases etc para ap de pagamentos então
esses pagamentos únicos né que a gente
que é o que sempre existiu né Eles
continuam lá esses testes eh obviamente
adaptados para paraas eh Por exemplo
agora o o post piak payment é uma Array
né então o motor tá fazendo as chamadas
com Array etc então obviamente todos os
testes adaptados mas a estrutura do
teste a gente vai mostrar daqui a pouco
ela se mantém bem similar aqui né então
esse plano aqui que é o plano principal
ele vai ter esses testes eh os testes
regulares digamos assim eles vão ter os
os testes web Hook e os testes de
agendamento recorrente um ponto de
atenção é que a gente ainda tem aquela
questão dos Testes que são o plano de
teste obrigatório para todo mundo e a
gente tem dentro do plano alguns testes
que são opcionais que são os relativos à
temporização e múltiplas alçadas né
então esses dois testes a gente tem
aquele CPF que a gente coloca lá dentro
da configuração E aí se esse CPF não for
informado quando você executar o teste
ele vai tá skied se você informar um CPF
específico para temporização específico
para múltiplas alçadas ele vai rodar
aquele teste ali e a gente vai vai ter o
comportamento dele testado né
basicamente então se a instituição
suporta temporização em múltiplas
alçadas ela vai ter que eh ela vai ter
que passar CP vai ter que executar esses
testes também
eh e aí passando desse primeiro plano de
testes né indo pro segundo ali que é rdn
a gente até com muito feedback do
ecossistema né os testes de kdn a gente
tem que gerar o kdn dentro do ambiente
pix tester e a gente entende que isso é
uma dor porque a gente só pode usar uma
vez né então eu crio crio um plano de
teste com antes né com 40 50 módulos se
eu US repit rdn tivesse errado tinha que
criar um novo plano para enviar paraa
certificação então isso tornava o
processo de certificação um pouco mais
doloroso né Então o que foi feito aqui
basicamente que a gente separou todos os
testes de crdn eh a gente já tinha feito
isso para V3 também né Justamente a
gente poder executar esse eh em paralelo
né então posso executando nos outros
testes e eu vou testando k rdn até
passar ali sem sem ficar precisando re
executar vários dos dos módulos que eu
já tinha passado né então só ess aquela
tarefa manual de execução a gente tá
tentando tirar isso o máximo possível e
terceiro teste de time Zone essa também
foi uma demanda que surgiu na V3 então
acredito que todo mundo que já tem
implementado a V3 vai tá habituado já
que é basicamente a gente garantir que
eu consigo fazer um pagamento entre um
período específico que é entre 9 horas e
2359 e isso é porque também né é muito
fruto de feedback do próprio ecossistema
existiam pagamentos nesses horários que
estavam sendo negados por conta do
entend AD então algumas instituições
estavam eh ajustando o horário para o TC
né que é horário 00er e aqui no Brasil
né horário de Brasília menos TR então às
vezes gerava conflito do entend id ser
mandado pro ti seguinte ou alguma coisa
nesse sentido Então a gente tem um plano
de teste separado eh com um teste que
tem que ser executado nesse período o
teste ele pode ser executado a qualquer
horário na realidade então não tem uma
exigência de ser executado nesse período
Mas você só vai ter sucesso no teste se
você executar nesse período né Então a
nossa recomendação é aqui que durante o
o o expediente padrão ali né a gente
consiga fazer as validações dos Testes a
última validação do teste é checar o
horário então se você verifica se você
tá passando no teste aí depois a gente
consegue criar um plano de teste
separado Então não precisa ser a mesma
pessoa que iniciou a execução dos outros
testes aí ele consegue clicar ali para
executar rodar o teste e tem um page aí
esses três planos vão ser enviados eh
paraa certificação então dado esse
contexto geral agora Fabi eu vou pegar
sua tela rapidinho depois eu te
devolvo mas acho que vocês já estão
vendo show Então pessoal eh eu sei que o
motor é algo bem comum aqui pra gente né
No que sistema eu só queria ter certeza
de que todo mundo entende eh os ativos
que a gente tem para facilitar o
processo de desenvolvimento dentro das
casas né a gente sabe que nenhum
processo de certificação é um processo
fácil é um processo doloroso Ainda mais
quando a gente tá falando de
especificações complexas como as nossas
aqui dentro do Open finance e também com
mudanças né que vão acontecendo no meio
do caminho aqui porque a gente recebe
esse feedback do ecossistema recebe
melhorias e a gente sempre quer deixar
ali garantir que que o ecossistema vai
est interoperar da maneira adequada né
então a gente sabe que não é um processo
fácil Justamente por isso a gente tenta
manter uma série de ativos aqui dentro
do repositório do próprio motor que
podem facilitar o processo
desenvolvimento o foco não vai ser esse
né mas eu queria só dar uma passada aqui
nesses ativos bem rápido para ter
certeza né e peço perdão se eu tô sendo
obtivo aqui pra maioria mas só para ter
certeza de que todo mundo entende o que
que a gente tem aqui para facilitar o
desenvolvimento né Então as duas páginas
principais essa aqui é a tela do motor
né o repositório do motor acredito que
todo mundo tem acesso se não tiver eu
vou colocar coloco o link aqui no chat
na sequência E aí tem duas páginas
principais aqui que eu acho que é
importante pra gente destacar A primeira
é wik e a segunda é a página de isos né
então entrando na wik
primeiro deixa carregar aqui aqui o meu
o meu ele tá pinado né mas ele
geralmente fica aqui dentro do das
abinhas aqui depois eu posso se alguém
tiver alum uma dúvida eu posso ajudar
também achar mas basicamente a página de
wik ela é a página da documentação então
toda toda a documentação do motor
incluindo a documentação dos Testes
instruções de como executar os testes de
ajuda para rodar local inclusão por
exemplo dentro do pipeline que acho que
muitas empresas aqui fazem também então
todo é como rodar um motor por exemplo
por api né pra gente não ter que ficar
executando manualmente esse tipo de
coisa a gente tem documentações aqui mas
o o ponto que eu queria focar da direita
aqui né a gente tem todas essas eh todos
esses ativos aqui que depois o pessoal
pode explorar não vou entrar em todos
eles o que eu queria focar aqui são nos
test plans esses test plans é a
documentação dos planos de teste né
então falando especificamente aqui a
gente tem desde fase 1 até 4B hoje a
gente tá falando de 3 v4 né então fase
três aqui a gente tem 3 V2 3 V3 v4
pagamentos sem redirecionamento
pagamentos automáticos E aí hoje aqui se
a gente entrar em 3 v4 a gente já tem
ali o release Notes
eh para ser usado a estrutura do release
Notes né a gente tem acho que os pontos
mais importantes são esses três os
últimos aqui geralmente que são as datas
de release as Breaking Changes e a a o a
lista de plano de teste a Fabia vai
falar bastante também sobre processo de
maturidade de desenvolvimento então não
vou me explorar profundamente aqui mas
só para passar né aqui dentro do então
do release Notes a gente tem como eu
comentei release dates vão ser as datas
aqui que a gente vai estar soltando
testes quando tiver alteração também por
exemplo uma alteração que eh adicionamos
novos testes mudou o teste etc a gente
adiciona aqui todas essas alterações
macro aqui dentro do do dentro do motor
né né e eu já vou mostrar onde que a
gente consegue ver essas mudanças micro
também é possível eh então a gente aqui
vai colocar as L dates obviamente esse
aqui o portal oficial é o portal
desenvolvedor lá a gente tem todas as
datas a FAB para 3 v4 também vai passar
aqui na sequência então vai ficar claro
para todo mundo mas a gente deixa isso
no re noes segundo ponto bem importante
que a Fabi vai vai comentar mais
extensivamente aqui né são as Breaking
Changes Então como a gente comentou né a
gente solta uma especificação né que
dentro do como estrutura e a gente tem
uma especificação que é Beta 1 e ela vai
evoluindo paraa beta 2 beta3 RC etc e
conforme essas evoluções vão acontecendo
mudanças podem acontecer na
especificação E aí se tem mudança na
especificação tem mudança no motor
também né então porque como eu comentei
o motor el basicamente o espelho da
especificação né se a gente muda um lado
a gente tem que mudar o outro também
para garantir que o sistema tá tá tá
aderente àquilo que tá sendo colocado
ali então as Breaking Changes a aqui a
gente vai sempre colocar qual que foi a
última mudança relevante né Por que que
isso é importante porque essa mudança
relevante vai ser a data aceita pela
certificação o motor de conformidade ele
para para ter um versionamento né então
a gente imagina que a gente cria um
plano e eu tô executando o plano e
dentro do plano que eu tô executando as
coisas começam a mudar ali né acho que a
gestão de mudança não vai ficar muito
clara então Justamente por isso o motor
de motor de conformidade ele tem uma uma
uma uma estrutura div versionamento né
onde para você ter acesso às novas
versões você tem que ir ativamente e
criar um novo plano de teste né então
esse plano de teste ele fica eu vou
abrir aqui na paralelo já e daqui a
pouco a gente passa mas esse plano de o
o o a data de criação do plano de teste
ele dentro do motor ali vend no plano de
teste quando que foi criado e essa
braking Change é importante porque é a
partir dela que vai ser aceito um pedido
de certificação né então aqui né só dar
um exemplo por exemplo do que aconteceu
em 3 V3 a gente tem aqui né a última
mudança relevante dia 21/9 uma descrição
daça os isos a gente tem aqui vou
entrar na página de ISO aqui aqui dentro
desse link de eh do link de de do do is
do gitlab a gente vai ter a descrição
discussão como fóruns comun que a gente
tem de desenvolvimento né então aqui a
gente interage bastante com os
participantes acho que a grande parte do
pessoal que já deve ter interagido com a
gente pelo gitlab ali né E aí vai ter a
descrição do que que é a mudança por que
tá mudando número de pessoas impactadas
etc né E aí lá dentro da da release
Notes né de 3 v4 a gente não tem né Como
comentei os test foram sol só uma semana
então a gente ainda não teve um feedback
Que altere o comportamento dos Testes da
maneira como eles estão Mas se a gente
tiver ou quando a gente tiver a gente
vai colocar lá no release Notes E aí só
entrando rapidinho como eu comentei na
página de isos esse aqui é o lugar onde
a gente vai conseguir ver tudo o que tá
acontecendo dentro do motor né e a
página dis gitlab a gente tem o service
desk né que é onde a gente vai receber
esses pedidos geralmente Então os
pedidos podem continuar normalmente né
chegando dentro do service desk o que a
gente faz é que a gente sempre replica
um ISO que chega no service desk para cá
para quê né para ficar visual para ficar
visível para todo mundo do ecossistema
Então dentro dessa página de isos aqui e
qualquer qualquer pessoa consegue entrar
entrar aqui dar uma olhada no que tá
acontecendo essa olhada aqui a gente tem
essa política de tags então vocês vão
ver que aqui os esses problemas né el
geralmente tem dois tags uma é relativa
a fase e outra é relativa ao que que é
aquela aquele ponto né então por exemplo
para 3 v4 se eu quiser saber o que tá
acontecendo eu clico nessa tag aqui de 3
v4 E aí eu vou ter acesso a tudo que tá
acontecendo no nível micro ou tudo que
aconteceu né tudo que já foi fechado
para 3 v4 sejam perguntas então dúvidas
e esclarecimento aqui a gente coloca
aqui também sobre os testes a gente teve
aqui ó no final da semana passada já
dois pontos que foram levantados um
deles inclusive já tá com a correção
feita aqui provavelmente a gente deve
fazer o Deploy hoje eh e aí o outro a
gente tá corrigindo aqui foi aberto
também a no final da da semana passada
né então tudo que tiver aqui a gente
coloca então é sempre a tag de fase e o
demais é a tag se for um bug né porque é
um comportamento do teste o digamos
assim o comportamento prático do teste
não tá seguindo o Sumário e a gente vai
falar dos sumários em 2 minutos aqui Opa
é rapidinho aproveitando que você tá
falando sobre isso vai existir alguma
janela para para que vocês façam essa
atualização dessas correções e não
impacte os participantes nos testes que
estão em
andamento a gente vai entrar nesse
detalhe daqui a pouquinho vai vou
explicar como que vai ser o fluxo
Obrigado
imagina legal obrigado rulo obrigado
Fabi
eh então Seguindo aqui né todas as
interações estão visíveis aqui a gente
tá com essa já só entrando um pouquinho
né Don espol do que a Fabia vai comentar
aqui a gente vai eh a gente tem
melhorado o processo muito com base
também feedback do co sist tema aqui pra
gente conseguir fazer um fluxo de
desenvolvimento liberar fazer reliz aqui
de maneira que faça sentido para
ecossistema FAB vai entrar neles daqui a
pouquinho mas acho que o ponto principal
aqui que eu queria trazer é justamente
para essa página de isos e a página do e
é extremamente importante pra gente
acompanhar o ciclo de desenvolvimento do
motor Então o que tá acontecendo Quais
são as mudanças Breaking Change então né
se a gente olhar aqui por exemplo se eu
botar Label a gente pode ver aqui por
cima também né se eu procurar Label de
Breaking Change eu vou conseguir saber o
que que tá aconte acontecendo Então a
gente não tem nenhuma aberta a gente
teve a última aqui eh pra fase 2.2 né
então por exemplo Esse aqui foi o is que
a gente teve uma Breaking Change então a
gente consegue acompanhar todas essas
mudanças micro do que tá acontecendo o
que vai mudar qual teste mudou por eh de
maneira bem detalhada aqui dentro dos
isos do gitlab eh e aí dado esse
contexto geral pessoal volando um
pouquinho pro I eh pessoal eu tô vendo
que tem o pessoal levantando a mão eu
vou só seguir aqui mais por conta do
tempo e aí tem bastante coisa que a Fabi
vai abordar também E aí se a gente não
for respondido a gente volta no final e
aí S todas as dúvidas eu consigo ficar
mais fo necessário também pra gente
conversar sobre os testes e e etc né mas
só voltando mas por favor segurem as
dúvidas aí que elas são bem importantes
pra gente né pra gente conseguir voltar
nelas no final eh então voltando aqui na
planilha desculpa aqui
não n a gente tem primeira parte
overview Breaking Change como a gente
comentou tudo pode ser acompanhado ali
pelo pelos disos do kit leb por último
um ponto extremamente importante aqui
também é a lista do plano de teste essa
lista de plano de testes ela é descrita
al documentação do que vai acontecer em
cada teste a gente não consegue
documentar 100% de todas as validações
né porque acho que em um plano né em um
em um módulo de testes a gente
geralmente tem assim 1800 para 2000
validações que são feitas então a gente
não at ficar uma documentação muito en
fadon a gente documentar tudo mas a
gente tem assim o cenário geral que pode
ser usado né esse cenário aqui ele fica
disponível naquela parte de cima do
plano né então a gente tem aquela parte
Azul ali dentro do módulo eh eu posso
até deixa eu pegar um icho aqui e eu já
mostro só para ficar claro para todo
mundo acho que todo mundo tem visão mas
só para ter certeza de que isso tá claro
para todo mundo né deixa eu pegar um
test
aqui então dentro do plano aqui eu
peguei um plano de icho né então ele vai
tá
falhado aqui essa parte azul é a
descrição do do cenário né então é de
novo né Desculpa T sendo fadon aqui só
quero ter certeza que todo mundo tem
visão e conhecimento disso é que aqui a
gente tá falando
para
vai
fazer das chamadas aqui então vou fazer
uma chamada Assim espero essa resposta
depois eu faço uma chamada Assim espero
essa resposta depois outra chamada
espera resposta etc então a descrição de
tudo que tá acontecendo aqui ele tá ele
tá refletido aqui dentro desse cenário
né aqui dentro do do Wi Então dentro da
planilha ali embaixo a gente tem a
descrição eh de todos os cenários 3 v4
que tá disponível lá o pessoal também
pode baixar depois quiser olhar feedback
ainda né se tiver algum feedback sobre
os testes a gente viu que teve ichos que
foram abertos com base na própria
planilha manda pra gente que a gente vai
refletir aqui discutir gente se foi
necessário eh sobre a planilha né então
especificamente aqui sobre as mudanças
dois testes a gente tem dois Abas aqui
uma 3 v4 essa aqui é basicamente só
replicando todos os os módulos e planos
e qual que é o Sumário deles todos né
então se a gente somar tudo aqui eh a
gente per junto com os demais Ali né com
os outros planos a gente vai ter todos
os planos test estão disponíveis eh
Então essa aqui é é de maneira geral né
os planos com sumários e aqui a gente
manté do lado também um Change log e
fica mais fácil para todo mundo ter
visão e o que foi alterado né aqui do
lado a gente tem algumas e digamos assim
né você parar aqui e passar rapidamente
como eu comentei né não vai dar para
explorar todos os testes 100% é
basicamente replicação do que o Zé e do
que o o wendle comentaram Mas falando
sobre mudanças Gerais né do que
aconteceu nos testes A primeira foi em
relação a múltiplas alçadas então aqui a
gente teve dois testes que foram
cancelados né então a gente tinha antes
múltiplas alçadas quando a gente alterou
para do P C propor accepted né a gente
alterou isso de maneira que eh que agora
o consentimento que controla ali o
pagamento né si então esses testes onde
a gente fazia esse esse cancelamento do
pagamento no meio do múltiplas alçadas
eles caíram né não existem mais então a
gente conseguiu basicamente tirar a
necessidade de testes eh mantendo a
mesma funcionalidade o que mostra que
assim a qualidade da das especificações
eh tem aumentado aqui eh e o segundo né
aquele ponto que o Zé falou onde a gente
tem uma mensagem de erro 422 para
eh para múltiplas alçadas não consome o
consentimento então o quat geralmente
consum consentimento aqui a gente tem
uma mensagem específica que não vai
consumir então a gente basicamente testa
isso aqui né Faz um post payment espera
um 422 E aí depois dá um get consent e
vê se não foi alterado para consumido
ali o o consentimento né Então essa aqui
é a primeira digamos assim o primeiro
bloco de mudanças em relação a múltiplas
alçadas segundo um bloco relativo a
mudanças que não tiveram mudanças na
lógica O que significa que as chamadas
são as mesmas né só que por exemplo como
comentei o post pi o post piix payments
ele ele virou uma Array então na prática
todos os testes foram alterados para que
a gente possa ter essa chamada via Array
eh os testes web Hook também assim acho
que é mais para testar o cenários de web
Hook não vou entrar no detalhe deles
teste de X fap Então como o Zé comentou
também né a gente tem essa necessidade
de criação do X fap pela eh pela
detentora né E retornar isso justamente
para ter o para ter esse link lá dentro
da PCM Então a gente vai alterou o teste
de X fap que a gente já tinha para
conseguir ter acesso a para conseguir
testar esse comportamento aqui e por por
último que é que eu acho que a gente faz
mais sentido que a gente gastar um
tempinho é só eh que eu tenho dois
minutinhos aqui pra gente eh dos doos
novos testes né esses novos testes são
os testes relativos a a
eh pagamentos recorrentes né O que que a
gente testa basicamente é sempre assim a
gente vai testar o cenário feliz a gente
vai testar os AD cases cenários
infelizes Ou seja a gente testa ali como
se fosse o cenário padrão e a gente
começa a testar vários limites ali né e
eu vi que foi foram surgindo várias
perguntas aqui no chat conforme Oé foi
fal falando que muitos desses a gente já
traduziu em cenários aqui então acaba
que isso aqui também ajuda bastante né
para quem ainda não não conseguiu
recomenda que a leitura do plano de
teste para que possa entender de fato
Qual que é a lógica dentro a lógica
esperada ali dentro do dos Testes do
motor né e da especificação também então
falando sobre os cenários né basicamente
a gente primeiro tem cenário Core para
cada tipo de pagamento então um
pagamento diário um pagamento semanal um
pagamento mensal e um pagamento
cust aqui é gerar o consentimento fazer
o pagamento garantir o pagamento foi
feito e que pagamento foi agendado né na
prática porque feito seria no futuro
então primeiros cenários cenários padrão
de pagamento eh então aqui a gente tá
basicamente terando aquele Rapid Flow né
E aí depois a gente tem mais um teste
aqui como o Zé comentou né a gente tem
eh do anos de consentimento com
pagamento diário que possibilita que eu
faça 730 pagamentos né então aqui a
gente faz uma chamada com 729 pagamentos
e espera que esses pagamentos sejam
agendados né então é basicamente para
ajudar as instituições a testar essa
estrutura de desse Bet de pagamentos que
pode ser feito né na sequência a gente
tem que testar os limites do
consentimento então José falou também um
pouquinho sobre esse limite do
consentimento no sentido de eh quando
que tem Day of
the
Opa rismi todo mundo de novo se quiser
desmutar que tava algum obando tranquilo
Obrigado eh então do próximo teste aqui
né Eh a gente tem testar esse limite do
consentimento né então eu faço eu faço
um pagamento mensal com D + 60 e passo
60 pagamentos E aí a a detentora precisa
fazer esse cálculo né para saber se o
pagamento tá dentro desse limite de 2
anos né então a gente faz um jogo um
pouco com essas datas depois né A
questão de ajuste de datas então o
pessoal falou ali sobre a questão do do
agendamento de um dia que não existe né
então você fizer um pagamento mensal no
dia 31 E aí a regra é que isso sempre
tem que ser julgado pro próximo dia
válido né então a gente faz esse esse
esse pagamento né com usando dia 31 e o
mês que não existe por exemplo Então
esse pagamento não pode ser aceito todos
TM que ser cancelados muito do que o
José trouxe aqui né na sequência
quantidade de pagamentos então por
exemplo se Eu agendei cinco uma
quantidade de cinco eu tenho que mandar
cinco pagamentos Se Eu agendei seis eu
tenho que mandar seis então aqui a gente
manda menos pagamentos do que o agendado
e depois manda mais pagamentos do que o
agendado né e a gente espera sempre que
o pagamento que receba a mensagem 422
com pagamento divergente do
consentimento todos os pagamentos são
cancelados e eh na sequência aqui é uma
questão de da do pagamento de
c né
então alguma questão de datos podem na
sequência aqui né a gente vai lidar
basicamente o cenário de entry andid
então quando a gente faz o pagamento
eh a gente tem que ser feito o cálculo
né baseado no Ed eu consigo ver quando
que esse pagamento foi feito então se eu
quero fazer um pagamento semanal Toda
segunda começando hoje começando amanhã
né então só vale a partir da próxima
segunda eu quero fazer cinco pagamentos
a iniciadora tem calcular isso para
mandar o end id e a detentora tem que
checar o end ID né então isso tem que
fazer essa validação dos dois lados ali
e é basicamente o que a gente faz é isso
é mandar o ent ID válido né então mandar
datas inválidas ali do end ID com que
foi passado dentro do consentimento eh
penúltima ali né a gente tem a questão
do amount então todos os payloads
pagamentos né eles precisam ser digamos
assim né Com relação é seu que foi
definido no consentimento então aqui a
gente tem basicamente Manda uma série de
cinco pagamentos um deles tem uma mount
diferente espera que isso seja negado
também e por último é o end Point de pet
então a gente espera que
eh que esse endp aqui que quando a gente
faz esse pagamento a gente tá testando o
endp de pad payments para principalmente
relativo ao conente ID né então a gente
faz uma série de pagamentos cancela um
pagamento depois cancela todos baseados
no conente ID E aí a gente vê se se o
cancelamento de fato foi feito né então
em resumo pessoal como eu comentei a
gente não não consegue passar por tudo
tentei fazer uma passada geral aqui nos
principais
vou colocar o link aqui do do wik e da
dos testes para quem quiser olhar com
mais calma e acho que na sequência agora
Fabi ela vai falar muita coisa relativa
ao motor também então pode ser que S
algumas dúvidas que existem e e a gente
tá aberto ainda para feedback nos testes
então de novo se alguém olhar ali algum
problema deu cenário dos Testes que
motor tá com problema mand ticket Desk
mando no Gate laab que o nosso time tá
locado para poder atender vocês em assim
mais rápido possível né e é isso
obrigado
Fabi Obrigadão
Cris oi eh pessoal continuando aqui
então entrando na última parte antes das
dúvidas eh depois de tudo todo esse
contexto aqui que a gente teve o que que
é esperado das instituições né então
trazendo aqui um pouco para vocês como
que funciona esse fluxo todo né a gente
eh recebe a gente tem o dentro do Open
finance a gente tá especificando as apis
para muitas instituições Diferentes né
então às vezes uma coisa que pode
parecer Claro às vezes pode gerar uma
ambiguidade um entendimento diferente
então aqui a gente tem um ciclo de
feedback que ele é fundamental pra gente
poder ter uma interoperabilidade tá
realmente dentro do ecossistema então só
compartilhando com vocês Esse fluxo
depois que a gente tem uma criação de
demanda por exemplo vamos ter pagamento
recorrente eh o grupo de especificações
trabalha para para publicar a primeira
versão dessa ap que é o que a gente
chama da Beta 1 E aí com isso a é a a
rion ali começa o desenvolvimento do
motor o grupo de especifica o grupo de
certificação e as instituições começam o
desenvolvimento das próprias apis E aí
depois a gente começa esse ciclo de
feedback então Eh são levantados
problemas bugs sugestões melhorias
eh nas espf aí a gente avalia se é
alguma questão para as especificações se
alguma questão pro Motor com isso a
gente evolui as especificações então tem
beta 2 beta3 RC eh e Ass ass por diante
a gente vai corrigindo o motor Às vezes
pode ser algum bug que seja específico
do motor uma correção necessária ou a
especificação foi atualizada então
naturalmente o motor tem que ser
atualizado para est consistente
eh mas para isso a gente precisa desse
feedback então é por isso que surgiram
os Marcos tá então historicamente a
gente tinha muitos eh pontos que eram
levantados um dia antes do go Live e a
gente não tinha tempo de reação como
ecossistema Lembrando que eh pra gente a
gente tem que avaliar delibera isso no
conselho implementa no sweger atualiza
os testes e todas as instituições têm
que fazer as adaptações nas nas nas suas
próprias apis então por isso que os
Marcos estão aqui pra gente conseguir
antecipar esses pontos de atenção esses
pontos de
preocupação depois disso a gente chega
numa versão estável das apis que vai
gerar a versão estável do motor aí as
instituições executam a última versão do
motor que é o que a gente considera eh
bom o suficiente estável para
certificação submete os ticket no
service desk a gente faz o processamento
E aí a gente tem o go Live tá então aqui
é compartilhando para vocês um pouco
desse especialmente da parte de
maturidade tá é fundamental a
participação das instituições aqui tá
eh você tem um calendário
V vai é o último slide é o último slide
legal obrigado então vamos lá então como
que funciona o ciclo de maturidade então
aqui as instituições são corresponsáveis
pelo ecossistema e então também são
responsáveis pela qualidade do
lançamento dos produtos Então esse ciclo
de feedback ele é muito importante então
Eh As instituições irem desenvolvendo o
quanto antes as suas apis baseado nas
especificações eu sei que às vezes tem
alguns casos que acaba eh desenvolvendo
para passar nos testes mas assim tá na
dúvida O que tá no swager o que tá nas
especificações que é a verdade tá na
dúvida de um comportamento do teste abre
um ticket a gente vai avaliar tanto a
parte de testes quanto a parte de
especificação os times avaliam em
conjunto então todo esse fluxo de
feedback começar o quanto antes é
fundamental
eh e aí para isso a gente tem os Marcos
de certificação então o que que são os
Marcos de certificação são datas que são
estipuladas para as instituições
passarem em uma parte dos Testes então
aqui para fase para pagamentos
recorrentes a gente tem o que a gente tá
chamando de Marco a que eu vou explicar
depois depois depois eh ah eu vou entrar
aqui nas datas daqui a pouquinho mas
basicamente vamos lá a gente tá com 34
64 testes no Marco de 50% é esperado que
a sua instituição esteja passando em 32
desses testes tá então a gente tem todo
um controle aqui
eh Aí depois a gente tem um um dashboard
de acompanhamento que a gente pode
compartilhar com vocês também como como
obter o acesso mas é tão simples quanto
são 60 34 testes no total no Marco de
50% você tem que estar passando em 32 no
Marco de 100% você tem que estar
passando no 64 eh se a sua instituição
não passar nesses testes você vai ser
notificado pelo service desk tá então
importante o service desk é a forma que
a gente tem oficial de comunicação da
estrutura com as
instituições de maneira individual e
personalizada então importante os times
de vocês estarem atentos por ali também
o mar Fabi eu tô dando só o exemplo para
fazer a conta ali tá mas o de pagamento
recorrente vai ser de 40% beleza Segue o
fluxo aí obrigado imagina eh
para a gente tem algumas mudanças no
motor de conformidade que nem o
Christian tava explicando que elas podem
ser eh originadas tanto por feedback pro
Motor quanto por feedback das
especificações e a gente fala que essas
mudanças elas podem ser mais ou menos
restritivas uma mudança menos restritiva
é quando a As instituições que estavam
passando o comportamento delas continua
válido Então imagina só a gente tava
dentro do motor aceitando um código de
erro apenas para aquela situação e aí a
gente teve o esclarecimento de que na
verdade pode ser um ou outro então quem
tava mandando um código de erro continua
passando e quem tava mandando o outro
começa a passar quando a gente tem essas
mudanças menos restritivas se você já
tava passando você não precisa re
executar o teste tá o que a gente tem
são as Breaking Changes ali é quando são
as mudanças mais restritivas que por
exemplo a gente estava esperando um
código de erro a e agora o código de
erro B que tá sendo esperado Então quem
tava enviando a tava passando no teste e
não vai mais passar então quando a gente
tem uma Breaking change a gente vai
comunicar o ecossistema tem a página ali
do do release Notes que o Cris estava
mostrando a gente vai divulgar por
informa também qual é a expectativa
dessa Breaking gente tá no ar eh mas aí
quem tava passando nesses casos deixa de
passar todo mundo tem que re executar
tá eh a certificação da de renovação de
pagamento recorrente ela vai ser da
maneira regular então quando a gente
divulgar a versão estável do motor todo
mundo vai executar os testes nessa
última versão abre o ticket no service
desk vai colocar como anexo os logs dos
três planos de teste que a gente
conversou aqui a gente vai avaliar
internamente vai entrar em contato Se
precisar de alguma correção o
responsável legal assina o documento de
o termo de certificação e depois tem
entrado em produção tá então esse vai
ser o processo de certificação regular
eh detalhes de como vai ser o goli que a
gente vai ter convivência entre a V3 e a
v4 aí a gente manda detalhes
posteriormente e aqui alguns pontos de
atenção
eh para falar com vocês
eh a as apis têm que ser desenvolvidas
baseadas nas especificações e não no
motor de conformidade qualquer dúvida
questionamento abre um ticket no service
TK ou no gitlab que a gente vai avaliar
eh tem um tempo pra gente conseguir
fazer tanto a correção do motor quando
tem algum bug e tem um tempo também
quando tem um lançamento de uma nova
especificação uma nova versão beta 2
beta3 até o motor estar adequado a gente
Tem trabalhado muito nisso desde as
últimas certificações eh o nosso Foco
aqui vai ser trabalhar mais com a
comunicação Então olha estamos lançando
essa versão da api o motor vai est
adequado em tal dia eh e sempre que a
gente tiver alguma atualização dessas a
a gente já vai fazer uma avaliação
prévia se isso vai impactar algum Marco
ou não e manter todo mundo informado tá
um ponto de atenção aqui é como isso
depende do feedback eh a gente não
consegue às vezes avisar com tanta
antecedência então por favor fiquem
atentos ali aos informas às comunicações
a gente vai a gente tá trabalhando muito
nessa comunicação fluida com as
instituições tá então algum ponto
crítico foi identificado a gente vai
informá-los o mais breve possível de
quando isso vai est eh corrigido e o que
que é esperado de mudança de se tiver
alguma mudança de data qual que vai ser
a nova como ou se a gente vai
desconsiderar algum teste dentro daquele
Marco enfim vamos conversando
pontualmente
eh e o Último Ponto aqui de alerta é que
as para pro gove As instituições vão ter
que ter o perfil fap único implementado
então é fundamental que todo mundo
comece também o desenvolvimento do
perfil fap único o mais rápido possível
eh inclusive o tema do workshop de
amanhã E aí dúvidas do cronograma a
gente tem o Marco a que é o um
específico aqui pro dia 15 do 12 então
sexta-feira não dessa semana da próxima
aqui a gente pegou 13 testes que são
representativos de pagamentos
recorrentes e a instituição vai ter que
passar em dois tá eh a gente recomendou
dois testes específicos como a gente
ainda não divulgou o guia de experiência
do usuário a gente sugeriu dois testes
para evitar retrabalho do lado das
instituições Mas fica a cargo de vocês
dentro desses 13 testes vocês vão ter
que passar em dois até a sexta-feira que
vem tá aí eh no dia 10 de janeiro
sucesso em 40% dos Testes no dia 29 de
Janeiro 70 25% dos Testes e dia 19 de
Fevereiro em 100% dos Testes aí depois a
gente tem um tempinho aqui que é para
fechar pegar o feedback final que as
instituições podem mandar até a 100%
fechar a versão estável da api fechar a
versão estável dos Testes tudo dando
certo todos os pontos tendo sido
corrigidos antecipadamente o ideal
cenário que a gente busca é que nesse
período aqui de ajuste final de
documentação e de testes seja
simplesmente mudar o nú o nome da versão
tá Então vai sair de versão RC para
versão estável Essa é a expectativa
eh então contamos com o feedback de todo
mundo desde o começo mas caso tenha
algum ponto a ser ajustado vai ser
dentro desse período e aí a gente tem
aqui duas semanas para submissão dos
pedidos de certificação então é o
período que as instituições têm para re
executar os testes nessa última versão
eh e abrir o ticket no service desk
depois a gente tem mais uma semaninha
aqui pro processamento desses pedidos de
certificação e aqui a gente a gente vai
ter um período específico que não vai
ser direto o go Live tá então depois do
processamento dos pedidos de
certificação a gente vai ter aqui um
período de 20 dias que quando você Olha
o cronograma completo desse período ele
vai ser também
eh ele vai ser também um período de
realização do dcm paraa entrada em
produção do do fap único aí as
instituições que quiserem se adiantar já
quiserem fazer o dcm para eh testar o
pagamento recorrente testar bilateral
ente com alguma instituição aqui é o
período adequado E aí dia 15 de abril a
gente tem o go Live oficial e então é
esperado que todas as instituições
entrem em produção com a v4 da P de
pagamentos no dia 15 de abril e depois
até 15 de Julho e com o período de
convivência Fabiane Fabiane por favor e
uma questão aqui
eh já tá bem adiantado o processo
começou lá em outubro etc e tal
porém no nosso caso aqui a gente
não a gente ainda tá em análise em
função de outras demandas e
emergências vocês vão eh nos punir entre
aspas por não participar dessa rodada de
testes a iniciar em
fevereiro vamos levar vamos levar tinta
a a pergunta é nós vamos levar
tinta tá vamos lá eh aqui a gente não
tem controle sobre ações de supervisão
tá então ação de supervisão fica a cargo
da própria supervisão do Banco Central
aqui como estrutura a gente acompanha
quem tá executando os testes E aí aqui o
acompanhamento vai acontecer a partir de
15 de Dezembro tá então não é nem a
partir de fevereiro então a gente avalia
todas as instituições que estão
cumprindo que não tão cumprindo os
Marcos e elas são notificadas pelo
service desk caso não estejam cumprindo
tá E aí se for o caso de ter a da
instituição conseguir algum alguma
exceção pro cumprimento de algum Marco
da supervisão aí pode avaliar e aí
encaminhar pra gente aí a gente não
notifica mas caso não tenha tido alguma
autorização específica da supervisão
todo mundo é notificado aqui tá tá eh só
complementando então a
questão essa notificação do service desk
é daquelas que vai até o cio ou ela só
vai
diretamente a quem tá registrado lá e
que tá fazendo essa interface com
Hum eu entendo que a sua dúvida é em
relação aos ofícios que são enviados
pelo banco central assim entendo que o
que vai direto pro cio são os ofícios e
aí fica a cargo da supervisão se vai ser
enviado ou não a cargo do Banco Central
Eh esses tickets no service des que eles
vão paraa equipe de atendimento n2 da
própria instituição tá e e e e pra gente
solicitar para supervisão um adiamento
como é que eh qual que é o contato para
com quem que a gente fala aí tem que
falar diretamente com o contato da
supervisão da sua instituição que FOA da
sua instituição tá Elias Oi esse caso aí
é isso mesmo esse que a a a Fabiane
falou você tem que identificar aí dentro
da sua instituição quem é o o o contato
que responde oficialmente né pelo
sisbacen pelo sisbacen lá e e e
antecipar esse movimento normalmente
aqui no no banco a gente recebeu uma
requisição que ele chamam né o Ofício
com uma requisição
eh eh eh em caráter informativo pra
gente dar ciência que a gente tá a par
desses prazos
eh principalmente da da parte do do novo
do fap único né tá muito obrigado aí a
gente é importante se tu já tem essa
sinalização aí que tu não vai conseguir
participar dos Marcos é importante te
antecipar a isso junto ao regulador
realmente Ah beleza
Muito obrigado hein
imagina pessoal então acho que do que é
esperado das instituições aqui a
importância desse ciclo de feedback
quanto antes os pontos forem levantados
mais antecedência a gente tem para fazer
as devidas correções e para vocês o lado
das instituições aqui conseguirem eh
refletir isso também e a gente ter eh um
go Live o mais fluido possível aqui
depois a gente compartilha com vocês são
alguns links úteis então o portal do
desenvolvedor então onde tem as specs a
página de calendários informas eh
release Notes motor de conformidade o
gitlab para abertura dos tickets e o
próprio service desk então aqui é mais
informativo a gente compartilha com
vocês posteriormente esses links E aí
aqui a parte de dúvidas a gente fez um
consolidado das dúvidas que ainda não
foram respondidas no chat
eh Então deixa eu compartilhar aqui aí a
gente vai peço apoio aqui pro pessoal
pra
gente respondendo tá
eh que eu tô vendo aqui as que ainda não
foram respondidas
eh uma pergunta do Anderson poderiam
trazer em vossa documentação uma
paginação padrão para que todas as casas
pudessem implementar uma paginação
podendo ser parametrizado o volume de
pagamentos a serem retornados de acordo
com a sua experiência instra aí essa vou
pedir ajuda aqui do do Zé e do Wender
eh pessoal a gente Pens tem um outro
ponto eu acho que você pulou ali Fabiane
desculpa interromper vocês estão me
ouvindo pessoal sim sim eh primeiro Bom
dia a todos aí eu trabalho aqui som um
parceiro aqui do do Bradesco aqui na na
construção de APS Open finance e além
desse ponto também tem um outro uma
outra dúvida acima que atualmente a
gente tem um volume máximo aqui né na v4
de 730 pagamentos né considerando dois
anos ali eh de um agendamento diário e e
e considerando essa premissa Eu acredito
que a gente pode ter até um GAP aí
também na parte de especificação da
criação do post o que que é esse GAP ali
que eu acredito que possa ter ali né
hoje no post o consentimento tá dentro
do de um arrei e eu mandando um
consentimento dentro de um arrei eu
posso ter n pagamentos ali né elevados a
a
730 que pode ser um pouco nociva ali né
mesmo paraa infraestrutura do detentor
na na questão ali de de consentimento
talvez se o consentimento ficasse fora
do do payload Ali de do arrei a gente
poderia ter ali uma alimentação ali de
730 para criação né Eu não sei se se
ficou Claro esse ponto Anderson eu
queria primeiro entender essa parte que
você tá citando do consentimento ser uma
lista seu udio aqui Não ele tá dentro de
uma de um parâmetro de uma
lista quando você abre point em que
local do endp é o
Create ali na na parte da post con e não
po post pay perfeito ele é só um campo
ali dentro né isso ele é um campo dentro
de um de um de um post entendeu tá tudo
bem Qual é a dúvida ele é só o valor do
consciente a ele não vai ser diferente
ele vai ser repetir várias
vezes Ah ele vai repetir várias vezes
ali então exato ele é um só tá ele vai o
que a gente tem aqui é uma API em que
você tem um consentimento único que
permite o pagamento de um para um
um pagador para um recebedor n vezes o
que você tem aí é um campo para permitir
o relacionamento entre o pagamento e o
consentimento por isso a gente tem hoje
a jornada sem redirecionamento né a
gente tem ali a o a API de vínculo de
dispositivo essa api ela não utiliza o
escopo dinâmico de consentimento aonde
ela Passaria o consent e o consent ID tá
eh visto que não tem esse escopo ali a
nível de authorization server a gente
precisava ter esse valor de
consentimento dentro do endpoint para
permitir que as instituições casassem o
pagamento com o consentimento né eh você
pode ver que o campo ele tem inclusive
uma restrição que ele só é de
preenchimento obrigatório quando a a
iniciação tiver vido de um fluxo
específico Então é só para isso que ele
tá ali tá a gente não não trata da
criação dele então ele não tem um
consentimento para cada pagamento é um
consentimento só que Vai comandar n
pagamentos Beleza então a cardinalidade
dele então continua sendo um para um
certo perfeito a minha dúvida era só com
relação a cardinalidade dele né eu
fiquei assustado que se tivesse uma
cardinalidade ali de um para n Pag eh um
um payload ali né de criação de
pagamento para n consentimentos a gente
poderia ter algo meio catastrófico aqui
mas entendi acho que ficou Claro
perfeito então só só complementando o
que o Zé Henrique explicou né esse
consentimento é o mesmo que já vem no
token né Zé
então que já tá contido lá dentro do
Token que continua sendo o mesmo do
consentimento o o consent ID gerado no
post do consentimento é o mesmo consent
ID que tem que ser enviado no post do
pagamento perfeito para todas as
ocorrências situação isso para todas as
ocorrências se não for essa situação é o
poste do pagamento tem que ser recusado
tá com a devida devis reason l ou
qualquer um outro que se
encaixe isso
aí perfeito sobre a segunda parte
Anderson que você menciona da paginação
a gente tá estudando tá a gente entende
que podem ocorrer esses cenários
drásticos mas nós decidimos aguardar
para ver se realmente é um volume
considerável que necessite de de ajuste
x de paginação e esse tipo de de
trabalho de de Cash e coisas do tipo tá
então a gente tá aguardando ter mais
informações sobre a usabilidade da api
pra gente poder tomar essas decisões de
melhoria de comportamento ali né de
retornos e etc
tá não perfeito é porque assim né
considerando que a gente pode ter né
hoje na na especificação da consulta de
pagamentos e até na própria criação ali
um retorno de
730 registros eh
numa paulada só acredito que fica ruim
até pra arquitetura de gator entendeu do
detentor aqui como que vai a gente vai
retornar hoje 730 registros em um um
único e payload entendeu eu acredito que
seja até inviável isso em questão de de
quantidade mesmo de tamanho né de de
rest aqui né não é o tamanho Hoje não dá
acho que não dá para trafegar isso daí
no no gator aqui né do do fornecedor que
a gente usa de cloud aqui cara talvez aí
seja um ponto até se pensar ali pelo
tamanho do payload ali né alguns IPI
gators ali Eles não conseguem trafegar
esse tipo de de volume de registros
considerando ali o o o tamanho ali do do
payload que pode ser trafegado num no
response bar ali entendeu eh essa
decisão relacionado ao tamanho e
paginação e etc ele entra no mesmo no
mesmo conjunto ali das decisões de S né
a gente no momento tem tô criar uma
especificação que trate bem os pontos
que são realmente que vão acontecer com
mais frequência né E esses outros pontos
que a gente entende que são exceções a
gente vai primeiro entender o
comportamento para poder depois tomar
alguma alguma decisão que melhore esses
pontos de Dores Tá mas a gente tem que
primeiro a gente quer primeiro entender
quais são realmente os pontos de dores
pra gente não ficar gastando tempo
criando tratativas para algo que nem
acontece no ecossistema com tanta
frequência você entende então a gente
vai gastar o tempo realmente criando
tratativas pro que for realmente
apresentado como problema
tá Eu acho que só para poder fechar aqui
Anderson a ideia aqui Talvez né Eh como
a gente fez esse lançamento agora pode
ser que essa esse ajuste ou essa
adequação não sei tá a melhor forma que
a gente possa pensar e evoluir na nossa
na nossa api aqui tá mas eh inicialmente
a gente quer sentir como as casas vão
estar ali com um comportamento do que
foi especificado E caso a gente tenha
algum problema em relação aos slas a
gente vai trabalhar para poder melhorar
ess esse
ponto boa eh Fabi eu vi que tiveram aqui
algumas eh algumas
eh perguntas a gente foi respondendo eu
não sei qual que é a melhor dinâmica
porque eu acho que vale a pena a gente
pegar três aqui de especificação três TR
de conformidade três de para poder
passar né E aí talvez do informe a gente
mandar tudo detalhado que os pontos que
a gente acredita aqui em relação às
respostas pras instituições que que você
acha boa pode ser fica à vontade aí se
quiser passar pelos especificações a
gente tá tentando responder no chat a
maior parte possível
tá boa
eh eu vou pegar uma aqui e aí Zé eu vou
seguir ali o que você já tinha passado
mas por favor então
eh uma pergunta que foi comentada aqui
que eu tô tô lendo aqui foi do da do
Daniel eh às 10:13 aqui né Eh Bom dia ou
foram uma das primeiras Bom dia eh por
longa duração o entendimento que é até
24 meses não necessariamente 24 meses
certo está previsto mais de um
agendamento por dia a gente tá
respondendo chegou a colocar lá isso até
24 meses apenas apenas um agendamento
por dia apenas um por dia por
consentimento
eh George Martins fez uma pergunta ali
inspiration date time não é informado
durante o pedido de consentimento barra
post consente então o detentor de contas
vai gravar automaticamente 24 meses no
inspiration dat Será menor que 24 meses
apenas se o cliente revogar Esse foi o
nosso entendimento com a documentação aí
a nossa resposta aqui tá e a ideia aqui
é que você precisa definir o start date
e o quantity E aí a gente tá aqui
reforçando falando que a gente tá
trabalhando em cima da v4 né o
expiration dat time só é na v1 de
pagamentos automático e Zé se você
quiser complementar
aqui
desculpa o ainda tava falando no mudo
aqui pode continuar Ah legal
eh eu vou pegar um um outro caso aqui né
que foi da Juliana Peixoto o usuário vai
poder cancelar apenas o agendamento de
um mês específico ou sempre vai ser em
lote então só reforçando atualmente a
especificação hoje da v4 possuímos dois
end points um Pat payment Pay a que
cancela um agendamento específico
enquanto a gente tem um outro endp que é
o Pat pix payment conen consent ID que
cancela todos os pagamentos referentes
ao mesmo consentimento
então nessa sua pergunta aqui Juliana
caso você tem a necessidade de cancelar
um agendamento de um determinado mês
você pode usar o o end Point que cancela
aquele cara
especificamente
eh Eh
boa é isso adicionando a resposta do
Wender você pode cancelar tanto uma
ocorrência só na série de de recorrência
que você tem ou você pode cancelar toda
a recorrência de uma vez tá é
isso
boa eu vou Como eu como eu comentei a
gente passou aqui por por algumas das
perguntas tá eu acho que todos os inputs
que foram colocados aqui no chat a gente
vai responder vamos trazer mais
clarificações aqui mas dado o nosso
prazo aqui do horário eu vou passar aqui
pro pro bresler
eh ver aqui a questão das perguntas de
de ux tá E bresler você tem acesso aqui
ao documento você quer que eu faça a
leitura para ti
eh se puder ler a primeira para mim por
gentileza tá bom
eh pergunta do Marcos Vinícius às
10:36 a detentora não deverá validar as
datas validar as datas estão corretas
visto que no manual de experiência
poderá escolher por exemplo a cada duas
semanas informação que não vem num
consentimento perfeito
eh a a detentora não faz essa validação
a princípio eh e por isso que a gente
padroniza padronizou eh a comunicação de
sempre que a periodicidade for
personalizada Então sempre que ela for
personalizada tem ali o padrão como a
iniciadora deve enviar paraa detentora
isso vai no campo de texto pro usuário
foi eh o melhor
eh solução que a governança entendeu
para que a gente possa viabilizar sempre
também essas possibilidades
personalizadas sem estender ali eh a
tela do consentimento eh de confirmação
mostrando todas as datas por exemplo
então ali tem uma padronização ela é
específica sempre vai ser enviada dessa
forma e a detentora vai validar com o
usuário somente no momento do
consentimento ali também depois ele tem
a possibilidade também eh de fazer essa
validação posterior Eh Ou esse
acompanhamento posterior né na sua área
de gestão de Open finance tanto na
detentora quanto na iniciadora Mas são a
as datas que foram definidas pelo
usuário na iniciadora com uma facilidade
ali de interpretação que foi
padronizada boa BRZ eh eu acho que a
Elena aqui é uma segunda pergunta tá
bresler eu acho que é mais um pedido de
ajuste E aí só colocando aqui né toda a
documentação do guia ela tá passando por
revisões então A ideia é melhorar essa
informação para vocês vou aqui pra
pergunta tá bresle por o guia Dex faz
menção a implementação de outros
arranjos exemplo Ted nesse momento só
especificação para o arranjo do PX
entendo que o guia ter orientações que
não podem ser implementadas pelas
instituições só dificultam o trabalho
acho que esse conteúdo só deveria
aparecer no guia
eh quando o referido arranjo puder ser
de fato implementado até porque poderá
haver mudanças de acordo com a
funcionalidade adotada nas
especificações perfeito o guia ele tá
sempre passando por ajustes agora no
final do ano ele vai passar por uma
revisão também eh que a gente deve
trazer mais pro ano que vem eh no
subgrupo que tem eh o toda a questão do
guia de o x mesmo então que é definido a
forma como o guia é apresentado para
para todo o ecosistema eh e Agradeço
também e o o compartilhamento da da da
sugestão a gente traz para paraa
discussão interna aqui e já é algo que
tá sendo avaliado também entender essa
questão eh do Ted e etc o que a gente
gosta sempre de de reafirmar aqui que é
o compromisso do Banco Central é que a
iniciação de pagamento ela é agnóstica
para ela poder funcionar com qualquer
tipo de arranjo e a gente incorporar
mais arranjos no futuro eh entendendo
aqui a priorização do próprio Banco
Central também hoje com o pix que é de
fato aqui eh o que melhor atende né
todas as as especificidades e de pela
questão do pagamento instantâneo também
eh e da da e ter relação a que com todas
as casas eh a gente sempre começa aqui
pelo pix é o que faz mais sentido
comercialmente para pras instituições eh
mas a gente eh Tem essa possibilidade
também na iniciação de pagamento atuar
com outros arranjos no futuro e é
importante manter Esse aspecto agnóstico
também então só essa
pontuação boa e aí eu vou pegar uma mais
fácil aqui tá bresler Acho que já até
você tinha respondido que foi uma
pergunta do edvard Eh esses são os
requisitos do guia que foi comunicado
que será publicado até o dia 23/12 já
podemos considerar como a versão base
para iniciar a implementação dos canais
certo pode considerar como como
apresentação base sim eh no guia ali
eventualmente A informação é apresentada
eh por exemplo as telas né a gente vai
fazer ali as telas no mesmo padrão do
guia Mas você pode ter eh essa base aqui
ela vai permanecer vai ser eh mesmos
requisitos recomendações que a gente vai
ter ali tá então pode usar como base sim
é o intuito desse workshop da gente
conseguir trazer essas informações para
vocês esse contexto também nesse
momento boa brez obrigado Fabi partir de
conformidade Obrigado Wendel valeu
obrigada eh wend acho que eu até
resumiria aqui a parte de conformidade
tem algumas dúvidas aqui eu gostei da
sugestão a gente pegou todas aqui pelo
do chat depois a gente compartilha o
documento com as respostas acho que tem
alguns casos aqui que são de cronograma
que tem bastante dúvida até ajuste do
motor então assim estamos trabalhando
arduamente na comunicação com as
instituições eh então A ideia é sempre
que a gente eh tiver alguma informativo
algo que vá ser uma Breaking Change
alguma informação relevante a gente vai
compartilhando com vocês o Squad sbox
aqui tá trabalhando também para sempre
avaliar se vai ter algum impacto no
Marco questão os cronogramas então A
ideia é a gente passar informações cada
vez mais completas e ágeis para vocês
eh
e deixa eu dar mais uma
olhadinha aqui aí tem algumas dúvidas
sobre
eh a parte do que rdn ser gerado no pix
tester hoje a gente Até onde eu sei
todas as instituições geram pelo pix
tester entendo que se você gerar na
própria casa mas ele tiver vinculo lado
com o pix test pra gente poder validar
ali o o status do pagamento acredito que
não teria eh
problema e acho que no geral Essas eram
as perguntas que a gente ainda não tinha
respondido tem uma sugestão aqui uma
questão do plano de testa diferente para
pagamento recorrente e a do pagamento
regular geralmente planos mais planos de
testes acabam gerando um desconforto
para as instituições tá então por isso
que a gente Tenta colocar só casos de
exceção E aí nesse caso a gente tinha
optado por deixar tudo num o plano
tradicional todo consolidado mas se for
o caso ali a gente pode pode reavaliar e
separar os planos tá enfim precisamos
levar aqui internamente para para
verificar
eh pessoal aqui a gente até acabou
passando um pouco do do nosso tempo eh
esse workshop ele foi gravado a gente
vai compartilhar a gravação eh a gente
vai publicar no no canal do YouTube do
Open finance E aí a gente divulga o link
depois da gravação eh pelo por informa
também essa semana a gente tem mais dois
workshops então amanhã do perfil fap
único é super importante porque ele é um
dos viabilizadores até das
implementações aqui da das mudanças de
pagamento que vão ocorrer ali em abril
na sexta-feira a gente vai ter o
workshop de de
movimentações Eh aí desculpa gente tô
com sweeping accounts ainda na cabeça aí
Wenderson lembra Lembra o BR dia oito
transferências inteligentes
transferências inteligentes isso eh
Então vai ser aqui no final da semana
semana que vem a gente tem mais dois
workshops então queria agradecer aqui
todo mundo aqui o ecossistema todos os
grupos técnicos e todos os membros que
estão trabalhando arduamente nos grupos
técnicos para conseguir eh viabilizar
esses próximos go lives eh agradecer e
parabenizar todas as instituições porque
isso é a gente faz por vocês e isso não
sai se não tiver vocês do lado daí
também eh e a ideia é a gente conseguir
fortalecer e aproximar cada vez mais
essa relação tá então eh pode pode me
procurar pode abrir ticket no service
desk ticket no gitlab Estamos todos aqui
trabalhando para para fazer com que os
próximos go lives sejam o mais fluídos
possível então obrigada E espero
encontrá-los amanhã também e vamos em
frente Obrigadão bom dia a todos e boa
semana bom dia pessoal obrigado pessoal
bom dia obrigado P tch Tchau pessoal
obrigado Parabéns pessoal tchau tchau
Parabéns
pessoal