Workshop de lançamento de Transferências Inteligentes (v1.0.0 da API de Pagamentos automáticos)

Bom dia a todos queria agradecer a
presença de de todo mundo aqui então
estamos numa semana intensa de workshops
Então esse é o terceiro a gente já falou
sobre e pagamentos recorrentes a gente
já falou sobre o novo perfil fap único
Hoje a gente vai falar sobre
transferências inteligentes que é a nova
API de pagamentos que que que tá
surgindo aqui no open finance e semana
que vem a gente tem mais dois workshops
então queria agradecer a presença o
engajamento de todo mundo
eh teremos aqui Opa eh no mesmo formato
que dos outros workshop vai ser gravado
e disponibilizado posteriormente no
canal do YouTube as dúvidas podem ser
enviadas pelo chat elas vão ser
respondidas ou por mensagem aqui no
próprio chat ou no final do workshop no
momento de de perguntas eh e a gente vai
ter lembrando a todos mais dois
workshops na segunda-feira para apis
comum de produtos e serviços ali a a
fase um e na terça-feira
a nova versão da da API de consentimento
de recursos e a nova API de câmbio tá
então entrando aqui no nos
detalhes queria agradecer aqui também já
apresentar e hoje a gente vai ter o o
Wendel que é o nosso PM de produto aqui
para explicar um pouco sobre essa nova
api Qual o problema que ela vem para
resolver o Zé que é o nosso arquiteto
nosso api Expert Para apoiar aqui na no
detalhamento técnico do que vai ser do
que de como essa api vai funcionar o
bresler nosso aqui do do GTX que vem
explicar como que vai ser essa jornada
do usuário o chistian da rag aqui também
de da parte de testes vai vai explicar o
que vai ser testado como vai ser testado
motor ali de certificação funcional e eu
entro no finalzinho para falar com vocês
o que que vai ser esperado das
instituições nessa nessa parte tá então
queria agradecer todos os apresentadores
todos os membros dos GTS técnicos também
porque sem eles a gente não não estaria
chegando aqui nesse ponto e todo mundo
que tá aqui presente para assistir o
workshop e que vai ser responsável ali
por realmente desenvolver e colocar na
prática esse produto no ar então para
começar aqui quero passar a palavra pro
Wendel o que que é Trans o que que é
essa API de esse produto de
transferência inteligente o que que ele
vai fazer BO Fabi obrigado bom dia a
todos eh só reforçando aqui né
agradecimento aqui por toda essa
oportunidade da gente estar falando aqui
um pouco mais sobre eh todo o trabalho
que a gente vem desenvolvendo né e antes
de começar é só fazer um pequeno
disclaim aqui eu vou até pegar um
pouquinho da minha cola né que o
objetivo dessa apresentação aqui desse
workshop é falar não é falar do Pixel
automático mas sim falar aqui né de
todas as possibilidades que essa pi aqui
que a gente tá desenvolvendo pode
trabalhar em relação aos casos de usos
que a gente tem aqui para trabalhar
então essa api ela engloba três
funcionalidades que são diferentes né Eh
como eu disse a gente não vai falar do
Pixel automático mas a gente vai falar
da transferência inteligente aqui dentro
dela E aí antes de começar só mais um
agradecimento Quero Agradecer aqui eh de
novo né
Eh o GT serviços em relação às
instituições todo o funcionamento ali
participação das casas o secretariado os
coordenadores o grupo de produtos que
vem apoiando a gente aqui para poder
seguir dito isso eh Bora lá Fabi O que
que é a transferência inteligente né
então transferência inteligente nada
mais é do que um recurso que possibilita
movimentações financeiras de forma
automática de fundos que estão parados
eh na conta de um de um de uma pessoa eh
que eu consiga fazer essas movimentações
sempre paraa mesma titularidade isso
pode ser usado tanto para pessoas
naturais quanto para pessoas jurídicas
tá então o Por que que ela surgiu né
então dado toda a evolução natural aqui
do ecossistema em relação aos meios de
pagamentos Essa é mais uma
funcionalidade que veio para ser
embarcada aqui para ajudar as
instituições aqui em vários casos de
usos que a gente pode pensar e trabalhar
eh mais à frente aqui dentro da
apresentação eh só dando um spoiler
haverá aqui algum alguns exemplos
algumas situações que vão ser passadas
aqui detalhadas da melhor forma possível
tá turma Então qual que é o problema que
ela vem para solucionar né Essa
funcionalidade ela é tanto útil para os
consumidores individuais quanto para
empresas então assim quando a gente
pensa em casos de uso aqui a gente pode
pensar em algumas das possibilidades
aqui que estão descritas Mas como eu
disse vocês podem pensar e e aplicar da
melhor forma possível então eh a gente
pode pensar aqui na proteção contra o
uso desnecessário do cheque especial né
Eh
investimentos inteligentes de recursos
que estão parados em conta então você
consegue ali eh dar mais um um passo em
relação a a a como fazer a gestão em
cima do dos recursos que estão ali
dentro da da da sua conta para para para
uma aplicação né E também aqui a gente
pode trabalhar com o a gestão financeira
pessoal aqui seria um pfm né ou um pfn
ou ou o pf e o pfb Né o business ali que
também você pode trabalhar em cima disso
Quais são as principais funcionalidades
que a gente vai vai eh pensou aqui em
relação ao desenvolvimento dessa api né
então realização de transferências entre
mesma titularidade com ou a sem a
presença do usuário utilizando um único
consentimento em datas não
parametrizadas né então assim você
consegue deixar isso setado obrigado kin
eh você consegue deixar isso setado para
que os recursos possam ser transferidos
sem a presença ou com a presença do
usuário em datas não parametrizadas ali
sempre a partir de um gatilho
pré-estabelecidos tá quem é obrigado a
oferecer esse produto no final assim né
Eh dando aqui todo o contexto da do do
da da do ecossistema a obrigatoriedade
ela passa a ser ali para as detentoras
de contas oferecer a a solução e para
iniciadoras como uma forma opcional aqui
na na aplicação com isso eu passo aqui a
minha parte e a gente pode seguir aí
Fabi a palavra vai pro
Zé tá no mudo
Zé tá no mudo pelo tetin mesmo pronto Ah
resolveu resolveu Bom dia show bom dia
Bom dia
pessoal só um minutinho para ajeitar
aqui meu setup pronto
eh passando um pouquinho agora sobre a
parte técnica Primeiro vou me apresentar
né Eu sou o José trabalho aqui na
estrutura da dto junto do Wendel faço
parte do GT serviços ali eh e a gente
atuou bastante na construção dessa nova
api vou passar aqui pelo os principais
pontos da api e o que que é possível o
que que não é possível fazer devido a pi
ela não ser apenas de transferência né
inteligente ela é uma pi mais abrangente
ela tem outros produtos né então a gente
vai passar aqui no que no que é possível
fazer com a transferência inteligente e
o que que não é possível fazer tá E além
disso trazer alguns pontos comuns que
vão funcionar para qualquer produto como
máquina de estado web Hook e e assim por
diante Então a gente vai aqui a gente
tem um pequeno roteiro do que que a
gente vai falar a gente vai passar
primeiro Ali pela máquina de estados
eh eu vou pedir pra Fabi passar pra
próxima página por
favor perfeito aqui a gente tem
um o desenho da máquina de estados né
Vocês podem perceber que ela é bastante
semelhante à máquina de estados que a
gente tem ali na V3 e na v4 de
pagamentos com exceção do status que tem
ali no meio que é o
revoked vou já falar sobre ele
tá mas basicamente na jornada de criação
do consentimento vocês durante a criação
ele vai iniciar né a partir que o
momento que o iniciador faz o post
consent o consentimento cai alha ating
authorization
eh se houverem múltiplas alçadas eh esse
consentimento ele vai paraa pasa de
accepted né após a primeira aprovação o
consentimento vai paraa parte de
accepted essa primeira aprovação ela
precisa ocorrer em até 5 minutos tá
então durante a criação do consentimento
quando o usuário é redirecionado pro
ambiente autenticado do detentor né e
ele se autentica
eh ele tem até 5 minutos para aprovar tá
caso não esse consentimento já vai para
rejeitado
eh
falando beleza então ele aprovou o
usuário criou o consentimento aprovou
foi o primeiro aprovador aprovou e esse
consentimento tá em pxa de acept de
agora Então esse é o momento em que os
outros aprovadores precisam vir e
realizar a aprovação deles também tá
eh o prazo máximo para
aprovação como esse produto ele trata de
transferências automáticas e imediatas
digamos assim não tem uma cobrança
agendada que seja ditador pelo menos do
nosso lado para esse prazo de aprovação
tá então a política de aprovação de
múltiplas alçadas ela é aberta pro
detentor tá o detentor ele tem suas
políticas internas de aprovação de
múltipla alada que não são exclusivas do
Open finance tá Então segue as mesmas
regras internas do detentor que já tem e
o iniciador ele precisa ou ficar
realizando podem ou utilizar o mecanismo
de web que a gente vai falar um
pouquinho mais na frente
eh bom mas se não tiver um um
consentimento de múltipla alada como que
funciona a partir do momento que o
cliente entrou no ambiente do iniciador
e ele foi redirecionado pro detentor Ele
autorizou o detentor percebeu que aquele
cliente ele não tem mais de
um mais de um aprovador necessário paraa
conta né ele já pula ali de awaiting
authorization para authorized tá então
com
isso o consentimento dele já tá válido e
ele já pode começar a realizar
transações
eh dentro do do detentor utilizando o
consentimento tá
eh bom o que que é o revoked Né após o
consentimento já ter
sido aprovado e o o iniciador já tem ali
uma capacidade de ficar realizando
transações em nome do cliente
eh o cliente ele pode a qualquer momento
decidir ou revogar esse consentimento tá
como vocês podem ver pelo desenho só é
possível revogar aquilo que já foi
aprovado tá então consentimento a
revogação do consentimento ela passa
pelo endpoint de Patch que a gente tem
dentro da api assim como a
rejeição
então a gente vocês vão ver que a api
também ela permite que o iniciador nessa
api ela permite que o iniciador rejeite
também tá caso o iniciador detecte ali
depois que foi aprovado o
consentimento que ô perdão pessoal caso
o iniciador perceba antes da aprovação
do consentimento que aquela transação é
fraudulenta ele também pode chamar o
endp de pet e rejeitar esse
consentimento pelo lado dele também
dentro do detentor tá
eh a uma ação agora Falando
exclusivamente desse produto do de
transferências inteligentes Nós temos
dois critérios que movem o consentimento
para consumido tá o primeiro critério é
o expiration date
time perdão durante a criação do
consentimento o iniciador Pode informar
o detentor caso o cliente tenha
solicitado ao iniciador claro que aquele
consentimento ele tem um período máximo
de validade por exemplo 6 meses 1 ano 2
anos 3 anos assim como ele pode não ter
também tá um consentimento ele pode ser
válido enquanto não for revogado por
exemplo Tá
mas falando sobre os critérios de
consumação né um consentimento ele vai
ser consumido quando atingido o
expiration date time dele ou quando o
campo de um dos Campos de limite
opcionais que tão ali
que eu vou falar um pouquinho mais na
frente forem definidos o atingimento
desse valor também vai mover o
consentimento para consumido tá
eh eu acho que sobre a máquina de
estados é isso Fabi do consentimento
Pelo menos pode ir para próximo perfeito
aqui a gente tem a máquina de estados do
pagamento vocês podem observar que a
gente não tem o patc aí né Porque da
mesma maneira que nós levamos a multipla
alçada na quatro pro consentimento nós
mantivemos o mesmo comportamento aqui na
de paga na de pagamentos automáticos né
nas transferências inteligentes ela segu
a mesma máquina então é basicamente a
máquina que a gente já tem pagamentos
ali com os status received pending
scheduled accp acpd
acsc e assim por diante tá então acho
que não tem muito mistério aqui Caso
vocês tenham alguma dúvida sobre os
status da máquina podem perguntar aí no
chat que a gente responde tá
eh próximo Fabi por favor agora falando
um pouquinho sobre a impossibilidade da
edição do consentimento segura aí Fabi
esse slide não passa não
eh quando vocês abrirem o a
especificação da pay vocês vão perceber
que a gente tem um endp lá que ele é o
Patch pro consentimento que ele fala que
ele revoga rejeita ou edita um
consentimento porém essa edição de
consentimento ela não funciona pro
produto sweeping accounts tá
transferências
inteligentes esse essa edição ela tá lá
presente na api mas ela foi pensada
exclusivamente pro Pixel automático
nesse momento tá e como o pix automático
tá pausado a gente não tem essa
possibilidade nessa nesse primeiro
momento de utilizar a edição para esse
produto tá a gente entende que é tratar
de movimentações
instantâneas dentro da conta do usuário
onde não há possibilidade de
cancelamento apenas de contestação
eh a permitir a edição a logo na
primeira versão seria um pouco
arriscado então o grupo optou por não
permitir a edição para esse produto
nesse momento
e entender o comportamento e se
necessário né caso a gente enxergue que
tem muitas pessoas sendo prejudicadas na
jornada por não possuir essa capacidade
de edição nós trabalhamos para poder
permitir ou encontrar mecanismos
alternativos paraa realização
eh entrando agora no web
Hook abi por favor próximo perfeito aqui
a gente tem aquele mesmo desenho da
máquina de estados mas com algumas
considerações em cada um dos Estados né
eh nós mantivemos os status finais como
os status que são que serão notificados
né que é o consumido o rejected e o
revoked para essa
api e adicionalmente a isso nós
colocamos um um evento
condicional condicionante pro pro
disparo de notificações né Eh como o
iniciador agora para esse produto ele
digamos assim como esse produto não
possui
uma uma cobrança que já tá agendada que
pode ser o limitador para aprovação da
Múltipla
alada pode ser muito oneroso tanto pro
iniciador de ficar questionando toda
hora se aquele consentimento em em pasa
de accepted foi aprovado por todos e
quanto pode ser oneroso pro detentor
ficar recebendo esses questionamentos
todo o tempo para saber se aquele
produto foi aprovado por todos então por
todos se aquela transação foi aprovada
por todos os aprovadores né
então pensando nisso os iniciadores que
possuírem web Hook eles vão receber uma
notificação do detentor quando esse
consentimento que tava em P de accepted
tiver ido para
authorized então Obrigatoriamente um
detentor quando um consentimento tiver
quando um consentimento tiver transitado
de pxa de accep para authorized o
detentor precisa enviar uma notificação
de
webook quando consentimento tivesse
saído de a authorization para authorized
direto sem passar pelo pass accepted é
facultado ao detentor mandar tá ele pode
escolher mandar ou não se ele quiser
botar uma implementação única do lado
dele que chegou em autoriz ele manda não
tem problema tá ele pode mandar mas
Obrigatoriamente Nós só estamos nós
estamos pedindo que isso aconteça apenas
vindo do par accepted tá
bom PR próxima por
favor Aqui nós temos os eventos que
disparam web Hook na máquina de estados
do pagamento
eh vocês vão ver
que mantém-se né o mesmo comportamento
lá da v4 a gente não tem alterações nos
Estados o grupo entendeu que seriam os
mesmos estados os os estados
interessados em
notificação Então mantivemos as mesmas a
mesma estrutura de notificações pro
pagamento
tá pode ir Fabi
eh falando agora do período de vigência
do consentimento de longa duração né O
que é como eu falei lá atrás a gente tem
agora
o para esse produto especificamente Nós
temos duas maneiras de torná-lo ele
consumido né o período de vigência do
consentimento ele se inicia a partir do
dia definido no campo start date na
criação do
consentimento vocês abrirem a a
especificação da pi vocês vão encontrar
dentro do post recing consent um campo
chamado start date time esse campo start
date time ele vai representar a partir
de que dia aquele consentimento vai ser
válido precisa ser o dia atual Não não
precisa ser o dia atual eu quero que
esse cons eu quero que essas
transferências só possam ser ser válidas
sei lá daqui a 30 dias começa quero dar
esse consentimento pro iniciador mas
esse consentimento só vai poder ser
válido daqui a 30 dias porque eu tô com
pouco dinheiro eu não posso fazer agora
etc mas já tô planejando então eu posso
colocar o start date time para daqui a
30 dias no momento da criação tá
eh com isso esse vai ser o início do
período de vigência
eh como eu já falei não Obrigatoriamente
precisa ser o mesmo dia a única
obrigatoriedade que existe é que esse
start date time seja menor do que o
expiration date time
porque senão não tem como ocorrer uma
vigência né se você falar que o start é
depois da data de inspiração então
simplesmente não tem como criar o
consentimento tem parâmetros incoerentes
durante a criação
eh e o expiration date time como eu já
falei ele representa o fim da vida útil
daquele consentimento que é quando o
cliente no momento da criação decidiu
que aquele consentimento tem que durar 1
ano 2 6 meses 3 meses etc e quando
atingir essa data esse consentimento a
gente entende que esse consentimento já
teve já já cumpriu o papel dele né então
ele não vai para revogado porque não foi
isso que aconteceu ele cumpriu o papel
dele do jeito que o cliente solicitou
então ele vai para consumida no final
eh além disso a gente também tem os
parâmetros limitadores de transferência
O que são esses parâmetros imitadores de
transferência eles são como o próprio
nome diz né Eles imitam a quantidade de
as quantidades os valores e etc que
podem ser trafegados dentro
desse desse consentimento né eles são
divididos em um limite por período ou
por valor e esse por valor ele pode ser
um valor total acumulado ou por
transação tá eh só deixando um ponto bem
claro aqui não é obrigatório tá eh a
definição de algum limite pro produto
por quê Porque a gente entende que o
arranjo pix todos todas as
transferências feitas para esse produto
de transferências inteligentes ele vai
estar sujeita ao arranjo pix com isso o
o usuário dentro do detentor ele já tem
o limite do arranjo
definido seria um trabalho e uma gestão
a mais pro cliente trabal se ele fosse
obrigado a ter que definir um limite aí
também então talvez criasse alguma
fricção na jornada ou na experiência de
usabilidade dele que não é interessante
pra gente que isso aconteça então com
isso em discussões com GT deux nós
entendemos que não devemos obrigar a ter
mais de um limite devemos dar a
possibilidade de ter caso o cliente
queira mas não obrigá-lo a definir mais
algum tipo porque ele já tem o limitador
do arranjo então com isso já é
suficiente para ele poder limitar o
valor que ele quer transferir etc
Se for esse o caso de uso dele
né mas falando um pouco dos limites que
a gente tem a gente tem os limites por
período que é nós podemos configurar no
momento da criação do
consentimento por exemplo quantas
transferências diárias no máxximo a
gente quer permitir Qual o valor máximo
dessas transferências diárias a gente
também pode fazer essa configuração de
quantidade e de valor máximo que pode
ser feito para configuração na
configuração semanal mensal ou anual tá
então você pode falar que durante um mês
você quer permitir apenas 10 transações
e essas 10 transações não podem passar
de R 500 tá eh você pode definir que por
uma semana você vai realizar no máximo
duas transações e cada uma dessas
transações não pode passar R 200 esses
limites eles são complementares tá então
um limite ele tem que ser sempre checado
contra o outro tá um contra o outro
então você vê primeiro por exemplo o o
usuário defini o limite diário não ele
definiu o limite semanal definiu
então o limite semanal permite a
transação permite Então passa ele
definiu limite mensal definiu não
definiu não definiu ele definiu limite
anual não definiu então assim se o
limite que ele definiu o mensal permite
ele pode fazer tá
Eh agora sobre os limites de valor a
gente tem os dois limites de valor que é
o valor total acumulado e por transação
eh o valor total acumulado
ele vai tá na pi com nome Total allow
amount tá esse campo ele vai representar
o valor máximo que o cliente permitiu
para ser trafegado dentro daquele
consentimento somada todas as transações
que ocorreram dentro daquele
consentimento tá então a
responsabilidade do detentor garantir
que a próxima transação que vai
ocorrer perdão só ocorra quando o soma
quando ele já tiver concluído a última e
o somatório da última transação com essa
próxima transação que chegar não
ultrapassa esse limite tá
eh Se ultrapassar o limite no momento da
chamada do iniciador esse valor que o
iniciador enviou pro detentor
ultrapassar esse limite o detentor vai
rejeitar essa chamada a gente tem um
erro específico para isso que admite o
valor excedido tá o detentor vai
rejeitar essa chamada com essa rejeição
da chamada ele também não vai informar
quanto que sobrou de limite tá isso é
bem importante falar ele não ele não vai
te dizer ele não vai informar pro
iniciador Ah se você mandar r$ 2 a mais
passa não tá ele só vai falar limite
valor excedido então o iniciador ele
pode informar pro uso usuário que não é
mais possível realizar transações usando
aquele consentimento e pedir a criação
de um novo
Eh E com isso revogar aquele
consentimento na ponta dele
e e criar um novo consentimento pro
cliente ou ele pode tentando realizar
transações até que ele encontre um valor
que passa tá nada impede ele de fazer
isso tá
eh eu acho que é isso quando a gente
fala P limit por transação e ele
funciona mais ou menos como aqueles
limitadores semanais que eu informei ali
em cima que a gente pode definir por
dias quantidades que podem ocorrer
dentro do período ou um limite por
dentro do período só que esse aqui por
transação ele não tá olhando um período
nenhum ele é realmente por transação
então independente do período ele vai
checar se a transação tá s tá dentro
daquele limite tá então por exemplo eh
eu coloquei um limite de qu de R 400 por
transação que é o campo transaction
limite eu coloquei um limite de R
400 estão me
ouvindo legal sim eu coloquei um limite
de R 400 No transaction limit Então se o
iniciador tentar fazer uma transação
acima desse valor o detentor vai
retornar um limite valor excedido porque
o valor da transação tá acima do valor
definido por máximo por transação né o
valor máximo definido por transação é
menor do que o valor que o iniciador
tentou realizar a transação
eh perfeito agora que a gente entrou
nessa falando um pouco dessa das
transações e dos pagamentos em si vamos
comentar sobre o envio dos sinais de
risco na etapa do pagamento O que é isso
né como nós estamos nós estamos falando
aqui de
transferências de transferências
inteligentes que podem ou ou não ocorrer
na presença do usuário né Desculpa Zé
aqui o o computador travou eu tô na
página certa ainda né tá tá cer Então tá
bom obrigada
eh quando a gente fala de realização de
transferências sem com ou sem a presença
do usuário e o produto sweep o produto
transferência inteligente ele se
caracteriza por uma transferência
imediata tem a possibilidade de
cancelamento como eu falei antes né não
é nada agendado eh como se fosse um pix
imediato ou coisa
assim o detentor ele precisa se sentir
confortável em aprovar essa transação
sabe imagina que o iniciador ele tenta
fazer uma transação enquanto o cliente
dele tá dormindo o detentor sei lá ele
Tent ele tem uma janela de criação de de
de pagamentos de meia-noite a 8 da manhã
o iniciador aí ele tenta fazer isso de
madrugada enquanto o cliente dele tá
dormindo e o detentor para se sentir
mais confortável
aprovando pode receber algumas
informações a mais no momento da no
momento da criação do pagamento tá nós
temos vários indicadores de sinais de
risco que se dividem entre sinais na
presença do usuário e sinais sem a
presença do usuário tá são dois objetos
separados Cada Um Com Seus Campos de
preenchimento de acordo com a
possibilidade né então sem a presença do
usuário você tem que informar a última
data que ele logou no iniciador você tem
que formar como iniciador no caso você
precisa informar a última data que ele
logou na sua aplicação e você precisaria
informar a data de registro da chave pix
dele caso ele tenha iniciado o pagamento
com chave né não tenha sido Manu
eh E caso ele esteja caso você esteja
realizando na presença do usuário você
precisa mandar várias informações do
dispositivo do sistema operacional
eh eh de
geolocalização e todas as todas as
informações precisam ser precisam ser
solicitadas pro cliente na aplicação né
e com tanto que ele dê permissão para
você recolher essas informações pode
enviar vocês vão perceber que algumas
informações não são obrigatórias de
serem enviadas mas outras são tá ali
dentro dos sinais de
risco falamos agora do sinal de risco
Vamos falar agora sobre consulta de
pagamentos usando um recing concent
ID bom uma vez
que o consentimento tá pronto tá setado
tá tudo bonitinho foi aprovado tá
autorizado para para ser utilizado e o
iniciador passa a realizar essas
transações
eh a partir do momento digamos assim que
ele acumulasse a uma certa quantidade de
transações ali
eh digamos assim bem bem
uma uma quantidade alta de transações
para aquele mesmo
consentimento talvez fosse um pouco
Custoso para ele ficar recuperando
informações uma a uma né assim um
pagamento a um pagamento por exemplo ele
quer mostrar pro cliente dele um um um
um tipo de extrato do que aconteceu ali
dentro ele teria que buscar payment ID
por payment ID para poder montar uma
visualização e exibir pro cliente
eh seria meio complexo de de seria
oneroso né primeiro quanto maior for
esse esse essa quantidade de pagamentos
mais mais chamadas ele teria que fazer
no detentor
E para isso Nós criamos
um para evitar isso né Essa essa grande
esse grande volume de chamadas para
trazer informações únicas de pagamentos
únicos Nós criamos um endpoint que ele é
um endpoint de pagamento Mas ele tem um
parâmetro de filtro né o query parameter
que você informa qual o consentimento a
sua associado a esses pagamentos então
ele vai buscar todos os pagamentos
realizados Associados a esse
concentimento é é um endp que a gente
tem dentro da P que é o get pix recing
payment vocês vão perceber que ele tá
sem sem nenhum parâmetro no pef né ele
vai ter parâmetros no query só de filtro
e além de você poder filtrar por reue in
concent eh tem outros dois parâmetros de
filtro também que é o start date e o end
date
eh passando esses dois parâmetros você
define uma janela de tempo em que ele
vai ter que buscar esses pagamentos
então além de você poder fazer uma
chamada que traz todos os pagamentos
associados ao consentimento você também
pode fazer uma chamada que traz esses
pagamentos associados ao consentimento e
uma determinada janela de tempo tá
eh transferências entre matriz e filial
com o mesmo radical
eh durante a criação do consentimento
nós temos um campo chamado crédit
dentro da P esse campo vocês vão
perceber que ele é um Ari Por que que
ele é um Ari nessa primeira versão para
poder permitir esse caso de uso de
gestão de caixa entre matriz e
filial vou continuar aqui para permitir
esse caso de uso entre matriz e
filial é necessário durante a criação do
consentimento que vocêe o
CNPJ todos esses recebedores que vão est
embaixo da da da da sua filial ali né
então por exemplo você tem a conta da
matriz e da empresa matriz né que tem o
seu CNPJ e ela vai ser o pagador no sua
na sua transação na hora que você tá
criando o consentimento você vai colocar
dentro do objeto creditors os CNPJ e os
nomes das instituições que você vai
querer permitir o a a transferência
entre elas tá das instituições não
perdão das das empresas das filiais que
você vai querer permitir a transferência
entre elas
eh cabe ao detentor validar
se se essa empresa realmente né ele vai
poder olhar ali pelo radical se o início
ali os primeiros dígitos antes da antes
do 1000 forem iguais ele vai perceber
que é realmente uma uma empresa de mesma
filial
eh e após isso né você cria o
consentimento provendo todas essas
informações de matrizes e filiais que
vão de de filiais que vão est permitindo
que você vai permitir que esse que essa
transferência ocorra E no momento do
pagamento Você vai precisar enviar um
objeto Zinho um document e esse objeto
vai ter o CNPJ do da filial que você tá
tentando mandar por que isso porque no
momento de criar o consentimento você
informa todos que você vai permitir a
transf
só que se no momento da liquidação você
não informar para Qual daqueles que você
definiu ali na na criação do
consentimento você quer mandar o o
detentor não tem como adivinhar para
Qual daqueles que você colocou que ele
quer que você tá desejando transferir
então para isso a gente cria um objeto
document dentro da AP e esse objeto
dentro do dos end Point de pagamento da
api no caso né E esse objeto vai receber
a informação do CPF ou do CNPJ né
Independente de ser esse us a gente vai
ter ali o dado do CPF do recebedor
tá falando agora da geração daap
interaction pelo detentor semelhante ao
que a gente teve ali na na v4 né que a
gente precisa adicionar isso por causa
da PCM a gente também vai precisar fazer
isso aqui essa já vai nascer com esse
comportamento
táo
inicie de um consentimento ou qualquer
requisição que ele faça dentro do
detentor xap interaction id o detentor
retorna para ele o ex fap interaction ID
que ele gerar e o iniciador vai ter que
acatar esse x fap interaction ID enviado
pelo detentor porque em momento de
report para PCM é muito importante que
nós tenhamos esses dois as duas pontas
falando a mesma língua pra gente poder
ter uma visão real dos cenários que
estão acontecendo dentro do ecossistema
tá eh eh além desse cenário onde o
iniciador não envia né a gente também
pode ter cenários onde o detentor não
consegue atender e nesses cenários caso
o detentor não consiga atender ele
também vai precisar gerar um xap
interaction ID na resposta dele de erro
que seja e informar pro iniciador e o
iniciador vai ter que
acatar acho que é isso pessoal falei
bastante
íssimo vocês estão conseguindo me
ouvir Sim
sim agora não
mais travou Fabi acho que agora foi
foi Muitíssimo obrigada pela sua
explicação
eh tem alguns pontos aqui no chat a
gente vai vai respondendo agora queria
passar palavra aqui pro bresle para
contar pra gente como que isso vai se
traduzir na jornada do usuário né então
dessa
parte legal Bom dia pessoal obrigado
pela presença de todos aí quem tá
assistindo também pelo YouTube sou
Gustavo bresler tô representando aqui o
GTX eh falando um pouco da jornada do
usuário requisitos recomendações e
trazendo também aqui algumas ilustrações
das Telas a gente começa aqui retomando
os casos de uso que o Wendel eh
mencionou no começo explicou muito bem
eh as transferências inteligentes como
o mercado chamava anteriormente aqui de
account sweeping é é o nome que eh
transferências inteligentes é o nome que
a gente tem aqui no Brasil eh ela vai
permitir a transferência automática
entre fundos de mesma titularidade casos
de uso que a gente vê aqui que podem ser
incorporados no iniciador São otimização
de gerenciamento financeiro eh cobertura
de eh contas negativadas de cheque
especial de maneira automática eh e
investimentos inteligentes e qualquer
outra situação que tenha um gatilho que
foi ali acordado com o usuário no
momento do do consentimento na
iniciadora eh o consentimento ele é
pré-estabelecido com parâmetros de
valores e períodos definidos eh e acho
que essa é uma é uma é um contexto geral
aqui pra gente poder tratar eh como que
vai ser essa solicitação do da iniciação
de pagamento no
iniciador
deve passar para mim por Fabi por
gentileza Opa passou mais legal então
agora no momento do iniciador o momento
da solicitação da iniciação eh de
transação de pagamento a gente começa
com alguns
requisitos o usuário nesse caso ele
sempre precisa ser informado sobre as
situações e os casos de uso em que os
Fundos dele vão ser movimentados de uma
conta para outra e nos casos de uso em
que o usuário não esteja presente como
foi comentado pelo José eh que existem
ali eh informações diferentes que são
enviadas nesse caso do usuário está
presente ou não está presente a
instituição ela sempre vai precisar
deixar claro pro usuário que podem
acontecer movimentações eh eh de acordo
com aqueles gatilhos e parâmetros
definidos pelo usuário eh mas quando ele
não esteja presente também o usuário ele
sempre deve ser informado que apenas as
contas de mesma titularidade eh podem
ser definidas como contas de destino
como contas recebedoras como foi
colocado agora as contas recebedoras
sempre precisam ter o mesmo CPF ou a
mesma raiz do CNPJ para pessoas
jurídicas e eh o momento de definição
dessas informações fica na iniciadora
pode ser definido antes ou depois do
consentimento eh e a possibilidade de
utilização aqui de chave pic inserção
manual e eh do inic também
poder passar pro próximo FBI por
gentileza Obrigado eh deve ser
disponibilizada sempre a opção pro
usuário se ele deseja estabelecer
limites máximos por transação ou por
período período diário semanal mensal
anual os limites eles podem ser
definidos tanto em valor como em número
de transações e o usuário também sempre
pode definir mais de um limite eh
periódico transacional ali eh ao mesmo
tempo que sejam complementares por
exemplo um limite Diário de r$ 1 100 um
limite mensal de r$ 1 1000 eh podem ser
eh utilizados ali pelo usuário ao mesmo
tempo essa opção sempre deve ser dada ao
usuário você quer definir limites
limites transacionais Limites por
transação limites periódicos e ele pode
optar por definir esses limites ou não
ele sempre deve eh ser informado também
que além desses limites estabelecidos
por ele no momento do consentimento ali
na iniciador no iniciador ele também eh
vai estar sujeito aos limites
transacionais da conta dele no caso aqui
dos limites pics que ele vai ter ali
junto com a instituição detentora de
conta dele também eles são prevalecentes
aos limites estabelecidos aqui para o
consentimento o prazo de autorização
pode ser por tempo indeterminado ou
indeterminado no caso do indeterminado
ele fica valendo até que seja encerrado
pelo usuário Aquela aquele consentimento
aquela
autorização e a validade do
consentimento sempre deve ser a mesma do
prazo da autorização ou caso ele defina
ali limites pelo número de transações
que eh vai ser o caso da última
transação ali definida pelo
usar o cliente também sempre deve ser
informado sobre a instituição iniciadora
que vai ser responsável por aquela
transação eh todo esse processo aqui eh
podem ocorrer parcerias de acordo com a
resolução conjunto número um eh E essas
parcerias precisam sempre eh definir Ali
quem que vai ser o iniciador que vai tá
fazendo aquela transação o cliente
também deve ser informado que a
transação ou as transações futuras dele
vão vão estar sujeitos à disponibilidade
de saldo no momento da efetivação e da
liquidação eh dentro da do iniciador
existem eh informações mínimas que
sempre precisam ser exibidas para o
usuário por exemplo a forma por exemplo
não todas aqui né a forma de pagamento
precisa sempre tá definida eh e e
descrita pro usuário no caso por exemplo
o PX a descrição da recorrência né Qual
que é a descrição dessa autorização aqui
que tá sendo dada pro usuário essa
informação vai ser eh enviada pelo campo
additional information eh da api eh e
aqui pode ser por exemplo uma gestão
financeira automatizada né algo que o
usuário consiga eh visualizar ali na sua
área de gestão e identificar eh eh o
qual que é o objetivo daquela
autorização daquele consentimento a
iniciadora também deve descrever eh os
gatilhos das transferências então eh
qualquer tipo de transferência
automática transferência programada
precisa est descrita pro usuário a
maneira que ela vai acontecer por
exemplo caso suas contas eh recebedoras
estejam eh negativadas serão ão enviadas
eh valores eh dentro do seu saldo de
outras contas para poder cobrir eh
aquele aquele aquela conta negativada ou
as informações aqui eh a seus valores
vão ser enviados para essa aplicação
automática no final do dia então esses
gatilhos sempre precisam estar descritos
pro usuário eh com clareza com
transparência para que ele saiba eh
exatamente quando que os Fundos dele vão
ser movimentados de forma automática o
valor previsto dos pagamentos caso esse
valor seja fixo a data de início do
consentimento quando que ele começa Como
José comentou ela não precisa ser
imediata a partir do momento do
consentimento Mas ela precisa tá sempre
descrita pro usuário o prazo de
autorização mesmo que ele seja
indeterminado precisa est descrito pro
usuário ou eh a quantidade de de
parcelas ali né a quantidade de eh
transações Eh caso elas sejam
determinadas ali nos limites
estabelecidos pelo usuário os limites
transacionais precisam ali também eh ser
eh eh exibidos para o usuário e o valor
da tarifa do serviço de iniciação de
transação de pagamento sempre que
houver agora a gente parte eh pro
momento dentro da detentora de conta eh
logo após a autenticação a detentora vai
exibir ali a tela de confirmação da
autorização do pagamento eh e ela também
tem informações mínimas que precisam ser
apresentad a forma de pagamento por
exemplo o PX a descrição da recorrência
como foi comentado as informações do
recebedor no caso aqui nome e CPF ou
CNPJ quando a gente tá falando de
arranjo pix aqui CPF sempre mascarado tá
eh o número da da conta de origem eh o
valor previsto dos pagamentos caso ele
seja fixo a data de início do
consentimento e o prazo de autorização
mesmo que ele seja indeterminado ou as
quantidad ou a quantidade de parcelas
caso elas sejam ali um limite
estabelecido pelo usuário os limites
transacionais o valor da tarifa de
iniciação de transação de pagamento
quando houver e a gente coloca aqui
também o número da autorização para que
o usuário tenha um número de
identificação daquela autorização
daquele
consentimento tem alguém aí com com a
voz
aberta esse número da autorização ele é
sempre o número final do consente ID eh
o número final do consente ID quando a
gente tira ali eh o prefixo eh o RN dois
pontos e instituição dois pontos tem
aquele número que vem logo depois Esse é
o número do consentimento é o número da
autorização que precisa ser estabelecido
pro usuário para caso ele precise fazer
algum suporte posteriormente ele tem ali
a identificação daquela autorização
daquele consentimento também eh tanto
com a instituição iniciadora quanto com
a instituição detentora
dentro da desse ambiente aqui de
confirmação da autorização do
consentimento eh Existem os requisitos e
recomendações Então como requisito o
parâmetro do consentimento que foi
configurado pelo usuário aqueles limites
transacionais limites de por período ou
por transação eles não devem ser abertos
predição nesse momento da detentora
apenas confirmação ou cancelamento
alteração sempre na na no iniciador e
como recomendação aqui eh como existem
esses limites que podem ser
complementados né os limites do
consentimento e os limites transacionais
da conta do usuário é extremamente
recomendado que as detentoras exibam os
limites transacionais que aquele usuário
eh tem com aquela instituição para
aquela conta então por exemplo seu
limite pix aqui diário eh para essa
conta El ele é de eh X R 1000 agora por
dia eh 200 reais no período da noite
então todos esses limites que o usuário
tiver eh naquela instituição para aquela
conta de para conta de mesma
titularidade né eventualmente é um
beneficiário cadastrado que pode ter um
limite diferenciado ali já também ele
precisa eh tá aqui ele precisa não é uma
grande é uma recomendação que ele esteja
sempre eh exibido ali no momento do
consentimento pro usuário ter essa
informação eh ali descrita
Principalmente quando a gente tá falando
aqui tá de um valor fixo e esse valor
fixo pode ou não ser maior do que aquele
limite que o usuário já tem caso ele
seja maior eh é importante dar dar esse
destaque também eh tudo isso é uma
recomendação também para as detentoras
informar o cliente que a transação vai
est sempre sujeita à disponibilidade de
saldo no momento da efetivação e o nome
e CPF do cliente que iniciou a jornada
eh pode ser apresentado no momento da
confirmação do consentimento também aqui
quando a gente tá falando de PJ em que a
gente costuma ter eh um aprovador e um
operador operador se ele tá iniciando a
transação eh é recomendado que o nome
cpf dele ali de login naquela lá
detentora eh sejam exibidos ali também
no momento da
confirmação aqui a gente traz alguns
exemplos eh de ilustrações de tela de
como poderia ser eh essa tela de
confirmação dentro da detentora então
aqui a gente tem eh o banco Smart como
um exemplo fictício de um iniciador ele
precisa da sua autorização para realizar
transferências Inteligentes da sua conta
de acordo com as regras abaixo e aqui
descritas todas as regras da autorização
Então as transferências eh serão
autorizadas apenas para contas de mesma
titularidade O titular é a Maria da
Silva CPF eh xyz nesse caso ela tá na
própria conta dela então não precisa ver
o CPF mascarado Ela já sabe qual que é a
a conta dela que ela tá logada ali não é
uma informação que está sendo enviada
para terceiros a gente tem aqui a conta
de origem no banco Cred de conta a conta
eh de número eh x a descrição da
autorização né como por exemplo gestão
financeira automatizada tipo de
transação pixs limites transacionais
aqui num caso de limite eh indeterminado
sem limite eh de de transferências né
não tem um limite ali imposto pelo
usuário eh por transação por período eh
tem a data de início e a data de
expiração e também descrito sempre o
iniciador daquelas transferências no
caso aqui o banco Smart e o ID da
autorização que é aquela parte final do
consente ID na segunda tela aqui a gente
tem um exemplo de PJ Tá o que que muda
aqui e ou outros exemplos que a gente
pode dar também então a gente tem aqui o
titular da empresa com a raiz do do CNPJ
a a empresa titular né com a raiz do
CNPJ a gente pode ter aqui por exemplo
eh eh o como foi definido os limites por
transação então um limite por transação
um limite diário um limite mensal e um
exemplo aqui também de prazo de
autorização indeterminado Então até que
o usuário decida encerrar aquela eh
transação isso aqui a maneira como isso
é descrito sempre a cargo de cada eh
instituição do seu tom de voz da maneira
como ela comunica com seu usuário mas
sempre com essa transparência explicando
pro usuário eh todos esses requisitos
aqui as regras da autorização
solicitante nesse caso aqui CPF
mascarado Quem foi o operador eh e o
iniciador também e o ID da
autorização após o usuário aqui
autorizar eh o o a autorização aqui de
consentimento ele é enviado de volta
para a instituição iniciadora eh e a
gente tem aqui também alguns requisitos
que são exibidos pro usuário no momento
de retorno então o usuário Ele sempre
vai ser eh recebido com comprovante esse
comprovante ele precisa ter no mínimo o
valor do pagamento a forma do pagamento
as informações referentes ao recebedor e
o pagador daquela transação a data eh do
dos pagamentos caso elas já sejam aqui
eh definidas periodicidade das
transações no caso de pagamentos
sucessivos que é o nosso caso aqui isso
é uma uma questão mais mais geral aqui
do guia também né que contempla outras
formas de pagamento o prazo do
consentimento eh os limites
transacionais o número da autorização
aquela parte final do conente id caso
exista alguma tarifa ali pelo iniciador
sendo cobrada para cada transação também
sendo exibida e qualquer outro tipo de
informação mínima que eh seja requerido
pelo arranjo de pagamento vigente né o
arranjo de pagamento que foi definido
pelo usuário qualquer outra informação
mínima do pix ou qualquer tipo de
arranjo que possa vir a ser incluído no
futuro o cliente também sempre precisa
ser informado que a qualquer momento ele
pode pode cancelar encerrar essa
autorização tanto no iniciador quanto na
detentora eh ele pode alterar os limites
transacionais que ele colocou que ele
estabeleceu ali para aquela autorização
no iniciador eh e na detentora e ele
pode alterar as contas recebedoras no
iniciador eh ele pode também caso seja
disponível pelo iniciador eh um uma
gestão de notificações né puxa eu quero
sempre ser notificado quando a minha
conta eh quando uma movimentação for
feita quando minha conta fic no negativo
qualquer tipo de notificação que seja
provida ali opcionalmente pelo iniciador
o usuário também eh pode alterar o o
recebimento dessas notificações ali no
no próprio iniciador essa comunicação
sempre é feita da parte do
iniciador E aí a gente vai aqui pra
parte de gestão a área de gestão de
pagamentos dentro do ambiente Open
finance de cada instituição que a gente
contempla requisitos e recomendações
tanto para iniciadores quanto para
detentores de conta a detentora de conta
iniciador sempre vão disponibilizar pro
usuário as funcionalidades de consulta
ao histórico de todos os consentimentos
então todas as autorizações que aquele
usuário já fez eh ao longo do seu
período de relacionamento com aquela
instituição estejam elas ativas
pendentes por exemplo ali tá dependendo
de uma múltipla alçada né Eh que elas já
tenham sido inspiradas ou já tenham sido
encerradas eh ela precisa est exibida
ali pro usuário poder eh conferir todo
esse histórico com a data de autorização
com a data de inspiração do cancelamento
quando já eh existir e as instituições
também tanto iniciador quanto detentora
eh devem mostrar o status sempre
atualizado precisa sempre est
sincronizado a informação que o usuário
vê no iniciador é a mesma eh informação
que o usuário precisa ver na detentora
de Conta as instituições também eh devem
disponibilizar o histórico das
movimentações então histórico dos
consentimentos ou autorizações como a
gente eh recomenda aqui eh dizer para
usuário e o histórico de todas as
transações transferências que foram
efetuadas ali dentro daquele
consentimento daquela autorização também
eh tanto pros consentimentos que estão
ativos quanto para aqueles que já foram
finalizados
eh o iniciador também ele sempre deve
dispor dessa área de gestão de contas
recebedoras como foi colocado aqui pelo
José eh a a trava para iniciação eh de
transferências inteligentes é o CPF ou a
raiz do CNPJ eh e eh o toda essa parte
de gestão das contas recebedoras fica a
cargo do iniciador e ele sempre deve
prover essa área de gestão pro usuário
eh após o consentimento também então
nessa toda essa parte de gestão de
pagamento ele pode ali incluir uma nova
conta alterar eh o as contas que ele já
tem ali excluir alguma nova alguma conta
que ele já colocou eh e que vão ser as
contas que vão tá disponíveis para
aquele consentimento ali como
recebedoras de transações sempre de
mesma titularidade e nos casos de
contratos de parcerias eh é sempre
importante garantir que o usuário tem
acesso à sua área de gestão essa área de
gestão é de sempre responsabilidade do
iniciador e o usuário sempre precisa
saber que aquele é um ambiente do
iniciador
como recomendações aqui pra parte de
gestão a gente recomenda fortemente que
eh dado todas essas possibilidades que o
usuário tem de gestão que estejam
existam ali funcionalidades para ajudar
ele na
par então funcionalidade de pesquisa que
ele CONSEG consiga pesquisar e
autorizações transações funcionalidades
de classificação filtros ali puxa eu
tenho eh dentro da minha parte de gestão
agendamentos recorrentes tenho
transferências inteligentes futuramente
aqui vai ter pics automático também
então caso o usuário consiga filtrar
essas informações é sempre interessante
eh o iniciador também precisa eh pode né
permitir que ele crie um apelido para
cada uma das suas contas Então puxa Essa
é a minha conta de recebimento essa é
uma conta que tem uma aplicação
automática por exemplo então eu tô
destinando ela como uma poupança para
uma viagem para um objetivo que eu tenho
aqui também então Eh sempre eh
interessante eh é uma recomendação que o
iniciador permita que o usuário possa
ali dar um apelido para cada tipo de
conta para facilitar Essa gestão eh e a
área eh da do iniciador também pode
incluir toda essa parte de gestão de
notificações por consentimento sempre
que disponível pelo iniciador a a parte
de notificações fica sempre a critério
de cada instituição cada instituição tem
um tipo de mensageria diferente e quando
tiver ali eh permitir Essa gestão de
notificações também pro usuário para que
ele possa definir quando que ele quer
ser informado por um push notification
por um SMS e-mail a maneira que ele
preferir ali que seja ofertada para
ele sempre tem eh temos aqui informações
mínimas que precisam estar descritas pro
usuário então novamente forma de
pagamento por exemplo pix a descrição da
recorrência eh os gatilhos eh de
transferências aqui no ambiente do
iniciador que tem o registro eh desses
gatilhos é sempre importante deixar eles
descritos transparentes pro usuário
quando que eh as suas eh os seus Fundos
vão ser movimentados ali de forma
programática eh as informações do
recebedor nome CPF ou CNPJ eh conta de
origem eh a data de início daquele
consentimento o prazo de autorização
mesmo que ele seja indeterminado ou a
quantidade de parcelas no caso de ter um
limite ali eh de transações também eh eh
informações referentes às contas
recebedoras no ambiente do iniciador eh
limites transacionais que foram
estabelecidos ali mesmo quando eh o
limite não exista eh ser eh explicitado
pro usuário que aquela autorização eh
não tem um limite estabelecido eh e o
valor eh de uma possível tarifa sempre
que ela
existir na parte aqui de revogação e a
alteração dos consentimentos então o
usuário sempre vai poder revogar aquele
consentimento vai poder encerrar aquela
autorização que ele deu para uma
transferência inteligente tanto no
ambiente do iniciador quanto no ambiente
da detentora de conta e com relação à
alteração Como José comentou aqui eh
hoje não é possível efetuar um pet né
uma alteração direto ali em um
consentimento então caso o usuário
deseja alterar qualquer um dos
parâmetros daquele consentimento que
foram eh autorizados na detentora de
conta é necessário que seja feito um
novo consentimento e o iniciador pode
tratar isso eh com o usuário ali também
eh no momento da ofertando para ele
algum tipo de alteração facilitada pré
populada ali mas sempre vai ser
necessário criar um novo consentimento
para aquela autorização uma nova
confirmação também na detentora de conta
e caso o usuário eh altere qualquer um
dos parâmetros que são definidos apenas
no iniciador apenas no iniciador por
exemplo quero incluir um novo gatilho
quero eh eh incluir aqui uma nova forma
que aquela transação pode ser programada
quero alterar as contas recebedoras
essas informações que são definidas
apenas no ambiente do iniciador eh não e
que não fazem parte ali eh das das
regras né do do consentimento que foram
aprovadas na detentora de conta elas
não
paramos de te ouvir
gesler oi oi voltei pessoal boa
desconectou e conectou de novo aqui
obrigado
eh então Eh todos esses parâmetros ali
eh que não são aqueles que estão
exibidos nas regras de autorização da
detentor de conta que são apenas
definidos iniciador eles não necessitam
criar um novo consentimento então o
usuário pode alterar os seus gatilhos e
pode alterar as suas contas recebedoras
ali direto no
iniciador legal e aqui a gente traz
algumas ilustrações de exemplo eh de
como poderia ser feita Essa gestão de
pagamentos no ambiente do iniciador e no
ambiente da detentora então aqui é um
possível ambiente de gestão Open finance
em que o usuário vai ter os seus
compartilhamentos os seus pagamentos que
já foram feitos ali por através de
iniciação de pagamento e autorizações de
pagamentos aqui no caso de pagamentos
sucessivos né persistentes aqui e
possibilidade de criar um novo
consentimento dentro dessa parte de
autorizações de pagamentos aqui os
filtros que a gente coloca como
sugeridos eh para as instituições então
que o usuário possa filtrar ali eh por
autorizações ativas pendentes inspiradas
finalizadas por tipo de autorização
então autorização de agendamento
autorização de transferências
inteligentes futuramente autorizações de
pixs automático que ele possa ver ali
quais estão ativas pendentes com eh
dados iniciais e ele clicando naquela
autorização no ambiente da detentora de
conta que eh a gente vê o nome do
iniciador que foi eh responsável por
aquela autorização que solicitou aquela
iniciação eh e com as informações
mínimas aqui que a gente comentou então
aqui nesse exemplo eh Num caso de gestão
financeira automatizada eh pessoa física
eh sem um limite de de transferências eh
limites transacionais com as datas de
início de inspiração o iniciador
definido o ID da autorização definido
sempre a possibilidade de encerrar
aquela autorização e aqui uma
recomendação também de que o usuário
pode gerenciar as contas recebedoras
daquela autorização eh no e no iniciador
que ele fez eh aquela solicitação e do
outro lado aqui naé na no próprio
iniciador também eh as mesmas coisas
diferença aqui que a gente tá mostrando
eh o detentor de conta em que foi feito
aquela autorização eh do iniciador
também a descrição dos gatilhos que
foram definidos ali para movimentações
eh automáticas então garantir saldo eh
em casos de lançamentos futuros usuário
Quer garantir que ele sempre tenha saldo
naquela contta no caso de lançamentos
futuros cobertura de contas negativadas
eh em out nas contas recebedoras manter
recursos não em conta com maior
rendimento automático que tem aplicação
automática quanto mais detalhes for
passado pro usuário com relação a esse
gatilho mais transparente for pro
usuário eh é é a intenção aqui de que
ele sempre terha muita clareza quando
que eh os seus recursos vão ser
movimentados quando ele não esteja
presente é muito importante que isso
sempre esteja Claro e transparente pro
usuário eh tipos de transação eh os
limites ali definidos a possibilidade
dele gerenciar as contas recebedoras
também para aquela autorização e a
possibilidade sempre dele encerrar
aquela autorização eh fique fique sempre
claro pro usuário que ele pode eh ali
também incluir novas contas excluir
encerrar as transações encerrar a
autorização a qualquer momento e eh que
tem a possibilidade também dele V não só
o histórico das autorizações e dentro de
cada autorização ali também eh que ele
possa ver o histórico das transações que
foram feitas para cada autorização então
aqui na última tela a gente vê aqui eh
um um extrato de todas as transações que
foram feitas eh para aquele usuário
dentro daquela autorização também legal
pessoal aqui algumas eh observações
adicionais e
eh José wend Fabi também se quiserem
complementar eh com relação aqui um
pouco mais técnico mas a gente tem
aquelas validações eh e e casos de erro
que são definidos pelo usuário eh que
são definidos na na detentora de conta
logo após a autorização do usuário então
todos aqueles rejection reason e aquelas
validações que acontecem entre o momento
da autorização logo após a a
autenticação perdão logo após a
autenticação do usuário na detentora de
conta e antes de ser exibida ali a tela
eh de autorização algumas dessas
tratativas já são feitas hoje eh de
forma automática então Eh os
consentimentos de longa duração eh no
caso aqui persistentes das
transferências inteligentes eh Eles não
têm essa característica eh de Saldo
insuficiente e valor acima do limite
então eles podem ser sempre permitidos
não vão passar por esse tipo de
validação eh e eh o usuário pode ali eh
até o momento da transação completar o
saldo dele ele pode fazer uma alteração
dos limites transacionais da conta dele
também então Eh eles são eh indiferentes
a esse tipo de consentimento
eh limite do período ou valor excedido
então quando a transação é negada né
aqui já no momento do pagamento quando a
transação é negada porque ultrapassou o
limite eh para para um usuário
específico eh eh ela sempre vai vai est
ali eh descrita também e limite eh de eh
por período de quantidade né a
quantidade de transação foi cedida que é
o erro eh quando o o usuário ele
estabelece um limite pela quantidade de
transações por exemplo uma transação por
dia
eh e aí ele vai ou a para autorização
toda ali né Ele tem 10 transações Então
esse é o o o erro ali que é exibido pro
usuário e com relação ao temporizador
que também é descrito no guia Dex hoje
eh o temporizador ele pass ele não vai
ser aplicado nas transferências eh
inteligentes eh qualquer transação ali
que tenha uma uma suspeita de fraude vai
ser rejeitada imediatamente na detentora
mesmo que sejam entre contas de mesma
titularidade e eh está previsto aqui o
manual de tempos a publicação aqui para
janeiro
também não sei se o José também quiser
complementar alguma coisa aqui mas toda
a parte de eh IX eh eh é isso que a
gente tem os requisitos recomendações e
algumas ilustrações aqui com sugestões
de jornada Obrigada
BR Muitíssimo obrigada wend não sei se
você quer complementar aqui não era isso
agradecer acho que o bresler conseguiu
sintetizar esses pontos aí relacionados
ali alguns casos do inje reason e partir
de temporização que a gente passou ali
mas ele trouxe bem
obrigado boa obrigado obrigada bre
pessoal e agora a gente vai pra parte de
como tudo isso vai ser testado como vai
ser como vão ser o a parte de testes e
certificação aí depois a gente vai
entrar al numa parte de o que que é
esperado das instituições nesse meio
tempo tá então vou passar a palavra aqui
agora pro Cristian então Cristian Bom
dia muito
obrigada vontade op Obrigada Fabi Bom
dia pessoal e então me apresentar aqui
pessoal me chamo trabalha na orig aqui a
gente trabalha junto também a estrutura
eh Inicial aqui para poder fornecer
motor de conformidade funcional aqui
então os testes funcionais né Eh aqui
especificamente para eh pagamentos
automáticos a gente vai falar
basicamente uma estrutura ali na mesma
estrutura que a gente falou eh no último
workshop então vou passar aqui
rapidamente né sobre qual que é o plano
de teste aqui no caso é mais simples
também do que a gente estava falando da
v4 que eram três aqui é só um depois vou
pegar a tela da Fabia aqui rapidinho vou
mostrar o relase Notes e a gente vai
passar pelos testes né A ideia é hoje a
gente gastar
eh mais tempo falando de fato sobre os
cenários falando sobre os testes mas de
novo o Zé e O Endel eh e o e o Gustavo
também facilitaram muito o trabalho aqui
falando sobre as especificações Porque
no final das contas o que a gente faz
dentro do motor é só refletir as
especificações em cenários práticos ali
né para ver se todo mundo teve o mesmo
entendimento conseguir pegar feedback
das especificações e tudo mais né então
Eh especificamente aqui para v1 né de
pagamentos automáticos a gente vai ter
Eh vamos ter né 17 testes e esses testes
como o pessoal comentou a gente apesar
da API de pagamentos automáticos a gente
ter lá eh pix automático já teve RP lá
na estrutura dentro do consentimento a
gente vai tá testando só sweeping
accounts a estrutura base da api né
então por exemplo a estrutura de
consentimento ela é unificada para vrp
sweeping accounts Pixel automático Então
a gente vai testar essa estrutura de
consentimento eh vai testar o sweeping
accounts e vai testar o Web Hook então a
gente não vai ter testes relativos a
Pixel automático vrp porque Essas são
features que vão ser e vão ser
eh deplo no ecossistema depois né vão
ser colocados no ecossistema depois
sobre planos de teste a gente tem um
plano de teste que é obrigatório para
todas as detentoras né que esse é o
payment test plano v4 ele é basicamente
esse plano ele vai ter esses 17 módulos
eu vou mostrar depois ele também a gente
vai subir ele hoje ele ainda não tá no
motor mas hoje até o final do dia a
gente vai subir com os primeiros
cenários vou falar um pouquinho aqui
também de Quais as datas e quais
cenários vão ser soltos em cada momento
esse plano vai ter os 17 testes então
diferente da v4 que a gente tem três
planos aqui a gente tem um plano único
né E aí na v4 a gente tem um plano para
kdn um um plano é o padrão e um plano
para para time Zone aqui a gente não tem
esse tipo de esses testes Então a gente
tem um plano único ali eh e aí os
módulos a gente tem módulos de múltiplas
alçadas né então Eh como Gustavo
comentou né temporização não vai est
agora então a gente não tem testes para
isso a gente tem os testes múltiplas
alçadas que é aquela mesma questão que a
gente tem em todos os testes lá né se a
gente passar o CPF na configuração você
vai executar o teste e se você não
passar o CPF na configuração ele vai ter
skipet então ele é obrigatório só para
as instituições que suportam múltiplas
alçadas Então vou pegar a tela aqui
rapidinho
febi fica à vontade Cris pode puxar aí
legal então pessoal coloquei aqui no
chat também já o link pro release Notes
aqui de pagamentos automáticos eh não
vou repetir o que a gente comentou no
último workshop mas a mesma estrutura é
mantida né aqui no release Notes a gente
vai manter as datas principais de
release aqui e aí se a gente quiser
acompanhar para quem quiser acompanhar
mais de perto todas as alterações que
estão sendo feitas no motor dentro dos
isos aqui a gente tem a descrição a
discussão de tudo né E aí Aqui também a
gente vai colocar depois a sessão de
Breaking Changes Então se a gente quem
quiser consultar Quais que foram as
últimas alterações feitas ali
eh eh vai est disponível aqui também
assim que que a gente soltar os testes a
gente vai adicionar isso também eh aqui
a gente tem a planilha com todos os
cenários de testes vou passar pra
planilha aqui na planilha a gente tem
duas Abas né então a gente vai ter duas
entregas para PR pro motor de pagamentos
automáticos a gente tem uma dia 8 que é
hoje então hoje a gente vai soltar três
testes e a FEB depois vai comentar um
pouquinho sobre os Marcos relativos
desses testes e no dia 22 a gente vai
soltar o restante dos Testes né então
totalizando 17 a gente solta três hoje
14 no dia 22
eh sobre os cenários em si a gente sabe
que existe assim eh muitos dos Testes né
existem a dependência do do gwx tá sendo
finalizado eh e aí também a gente
entende que existe uma estrutura de
desenvolvimento da da da das das das dos
participantes né então esse primeiro
Marco ele basicamente os testes são
relativos à camada de consentimento e
assim a gente tem dos eh digamos assim
né dos três testes dois deles não
envolvem o redirecionamento do usuário
então não tem a dependência nem da das
da da jornada ali da jornada de telas
etc né Eh então os cenários que vão ser
que a gente vai fazer o release hoje né
O primeiro é esse que a gente chamou de
sweeping accounts cons Sens Core sempre
que a gente tem um teste Core geralmente
é um teste padrão um caminho feliz ali n
então aqui basicamente é criar um criar
um consentimento e poder ser autorizado
né então a gente vai chamar o post
recing conen esperam 201 redireciona o
usuário quando o usuário voltar a gente
faz um Get No recr Constant e vê se foi
autorizado Então esse primeiro cenário
aqui É um cenário padrão envolve o
redirecionamento do usuário né mas é só
essa criar o consentimento redireciona
verifico se foi autorizado e Pronto né
nada nenhum nenhuma outra validação
nesse sentido esses outros dois módulos
eles são também eh só da Câmara de
consentimento quando eu comentei esse
primeiro aqui que é sing accounts in
valid credito é basicamente como pessoal
comentou aqui né swiping account ele é
uma modalidade para ser feita entre
contas de mesma titularidade Então o que
a gente faz aqui é basicamente tentar
criar um consentimento com eh um um
creditor aleatório digamos assim né E aí
esse creditor aleatório tem vai estar
diferindo do que é o log de uso vai est
diferindo do que o usuário que tá logado
na Instituição na ali na na detentora
então a gente espera um erro síncrono
aqui no PST
E aí o último cenário que vai ser eh a
gente vai fazer o Deploy hoje é o
rejected consent que é basicamente a
rejeição do consentimento antes do
redirecionamento né então imaginando ali
que o usuário quis ser redirecionado
naquele momento ele fechou o app ou
desistiu ou qualquer coisa então a
possibilidade através do endp de pet de
fazer a rejeição do consentimento né
então eu crio um consentimento dou um
get depois verifico que tem
authorization não vou redirecionar o
usuário eu chamo um Pat do Rec
E aí depois eu dou um get E aí verifico
se foi rejected então crio consentimento
não redireciona chamo um Pat verifico se
foi rejeitado né então esses três
cenários aqui o Marco a né FBI vai falar
daqui a pouco mas eles estão relativos a
esses três cenários que vão ser vão ser
feito o Deploy hoje
eh eles dois desses né não envolvem o
redirecionamento do usuário e todos eles
só testam a camada de consentimento né
então para quem tá desenvolvendo Imagino
que todo mundo vai começar pela camada
de consentimento assim que você tiver a
camada de consentimento já desenvolvida
na instituição Você já consegue executar
esses testes né não precisa desenvolver
todas as entps por exemplo para começar
para conseguir testar aqui então foi um
dos direcionais também pra gente soltar
escolher esses testes para soltar
primeiro eh Então feito aqui no dia 8
esse release no dia 22 a gente vai
soltar os outros 14 testes um ponto
diferente aqui dos outros planos que a
gente tem é que a gente testa né a a de
pagamentos com o creditor sempre
registrado lá no pix test né porque a
gente vai ter que fazer essa solicitação
de Pag pagamento a detentora vai ter que
chamar o pix tester para fazer então é
importante que o creditor esteja
registrado dentro do pix tester E aí
Aqui tem um problema porque a gente tem
um creditor padrão que a gente usava só
que esse creditor padrão não tá
registrado como usuário logado nas
detentoras né então a gente possibilitou
duas tem duas possibilidades aqui para
ser feito os testes uma é eh se você
colocar um log de user e esse log de
user vai ser enviado no creditor também
porque de novo né esse E aí a mesma
coisa para Business entity aqui né para
para para PJ
eh sempre que eu mandar esse log de user
eu vou eu vou replicar ele dentro do
creditor ali então se você quer usar um
usuário logado da sua instituição você
passa isso esse campo na configuração
ele vai ser replicado no creditor se
você não enviar a gente vai mandar o
usuário que a gente já tem registrado no
pix tester como logged user também E aí
o trabalho no caso da detentora vai ser
registrar esse CPF que é o CPF padrão
para todos os testes a gente vai colocar
também ali na descrição do teste qual
que é CPF ele vai ter que estar
registrado no ambiente da t tentora né
porque senão vou redirecionar um usuário
que não tem conta então duas opções aqui
né A primeira você passa um CPF dentro
da configuração e a gente replica isso
pro creditor segunda você não passa um
CPF na configuração e a gente replica o
creditor que tá o nosso creditor né que
tá registrado na no pix sester dentro do
e do log de user E aí fica a cargo da
detentora ter o registro desse CPF na no
ambiente sandbox ali para conseguir
executar os testes né Então acho que
essa é uma uma das Diferenças técnicas
com relação à execução dos Testes que
vai ser necessário mas fora isso é
basicamente testes padrões aqui e aí
seguindo pros demais cenários de novo a
gente vai repetir bastante coisa do que
o do que o Zé comentou aqui quando ele
falou das especificações a primeira né
revoked consent então dentro da api da
v1 aqui né a gente tem esse esse esse
status de revoked que é diferente da API
de pagamento de padrão porque se eu
chamava um pet elá ia para consumed né E
aqui o consumed é só de fato se eu
atingi o amount total ali que você como
limite Inicial então aqui eu chamo post
consent redireciona o usuário passo um
Pat verifico se tá revoked tento fazer
um pagamento e e espero que esteja
negado esse pagamento né então crio crio
o consentimento redireciona o usuário
deleta o consentimento vej time revoked
tento fazer um pagamento em sucesso
então o cenário aqui pra gente testar
esse novo esse novo status ali da
máquina de estado segundo ponto de
múltiplas alçadas né Então esse teste
múltiplas alçadas foi o que eu comentei
a gente vai ter um campo como a gente
tem assim em todos os planos né que é
esse CPF CNPJ payment consent for
multiple consent test se você informar
esse campo na configuração ele vai
executar esse teste com esse CPF se você
não informar esse campo na configuração
ele vai dar skip no teste né Então esse
teste aqui é obrigatório para Quem
suporta múltiplas alçadas o que ele vai
criar basicamente é chamar um post
Constant redireciona o usuário dá um get
vê se tá em partial accepted né então
isso aqui já foi introduzido inclusive
na v4 lá também eh então ele Verifica
esse partial accepted eh e aí ele vai
começar a fazer um p tenta fazer um
pagamento né então esse pagamento só eu
só posso ter realizado pagamento se
tiver em authorized espera um 422 com
consentimento inválido eh porque eu já
votei o autorisation Code nesse caso né
já que ele já foi redirecionado então é
uma trava na questão na camada de
negócios ali atrelada a ao Status de
consentimento então mesmo tendo
authorization code mesmo tendo pegando
token eu eu vou conseguir eu vou fazer
uma chamada Espero um 422 E aí depois a
gente começa a fazer um Get No para
verificar o estado do o estado do
consentimento até esse consentimento
está autorizado né Então nesse momento a
gente vai começar a fazer o get é
esperado que a detentora autorize o
consentimento né então segund
autorizador falsa autorização isso vai
para authorized quando for para
authorized a gente vai fazer um
pagamento e espera um 201 a gente não
vai checar o estado do pagamento mas eu
espero um 201 nessa chamada do essa
segunda chamada do pagamento com
consentimento já autorizado Então esse
segundo cenário aqui cria o
consentimento vejo tá em partial
accepted vou ficar fazendo um pulling
ali no get até ser authorized quando for
authorized eu faço um pagamento espero
201 então cenário de múltiplas alçadas
expiration date time o start date time
expiration date time é basicamente se
quando chegar o expiration date time eu
consigo eh eu não consigo mais fazer
pagamentos e o pagamento vai para
revoked então crio um consentimento
redireciona o usuário para autorizar eh
Espero um tempo para esse consentimento
inspirar verifico Depois dou get conen
né verifico se foi revogado com 201 faço
um pagamento espero 401 né de novo então
eu vou ter um autoriz code antigo aqui
vou ter um refresh token tudo mas quando
eu usar o o o expiration de time já
revogou o consentimento né atingi o
limite do consentimento e eu espero que
isso esteja consentimento esteja
revogado que eu não consiga fazer o
pagamento então basicamente esse teste
né eu chego no expiration date time
start date time aqui é o contrário né
então a gente tá testando aqui os dois
limites do consentimento tanto do início
quanto do fim aqui do start date time a
gente vai fazer uma chamada a gente vai
fazer vai criar um consentimento com o
início dele né então o start date time é
d+ 10 ou seja daqui a 10 dias E aí
depois eu faço um pagamento ou seja o
pagamento tem que ser negado de novo
Apesar de eu ter aqui né redireciona o
usuário o usuário volta eu pego
autorisation code E aí quando eu fizer a
chamada eu vou ter um pagamento que é tá
antes do start date time Então nesse
caso eh também tem que receber um 422
então aqui nesses dois testes a gente
testou os dois limites do consentimento
aqui tanto o o início quanto o fim
Seguindo aqui a gente tem o sweeping
account Spore test Model então aqui é
basicamente um teste que a gente vai
passar por todos os os end points
basicamente
a gente vai o CPF tá aqui né que a gente
comentou
eh quando eu vou fazer uma chamada com o
amount de 600 E aí o amount aqui pessoal
tem um ponto também que acho que vale a
pena já comentar é que a gente vai ter
esse campo amount foi o que o o Zé
comentou né sobre é um é uma é um campo
que vai ser passado e aí ele é somatório
de todos os pagamentos que já foram
feitos eh dentro desse consentimento e
aí quando eu atingi o cons quando eu
atingir esse total amount né ele vai
para consumed Então esse campo aqui a
gente tá passando ele como amount esse
para facilitar né A A tá em discussão
agora para para que seja facilitado e
entendimento né esse nome mude para acho
que Total S amount se eu não me engano
só que como a especificação do Portal
hoje ainda tá Mount os testes que vão
sair agora no dia 8 hoje eles estão com
a Mount ainda né Então vale o que tá na
especificação a gente não vai fazer nada
diferente da especificação ali eh e aí
quando isso for alterado a especificação
vai alterar o o motor vai alterar a
entende também que as detentoras vão ter
que alterar esse o nome desse Campo ali
né para para facilitar o
entendimento Então a gente vai mandar um
amount com 600 né voltando pro teste
aqui a gente tá no Core test Model a
gente vai mandar um amount com 600 crio
consentimento redireciona o usuário
Então eu só posso transferir r$ 600 né
dentro desse consentimento eh faço um
primeiro pagamento com 300 E aí eu
espero 201 vou ficar fazendo um pulling
até o pagamento ser aceito quando o
pagamento for for aceito lá CSC eu dou
um get verifico que você ainda tá em
authorized então de novo né que é
diferente porque sempre que a gente
falou em pagamentos quando eu faço
pagamento o consentimento já vai para
consumit aqui ele só vai para consumit
se eu atingir o limite lá do amount né
se eu consumir de fato todo eh todo
aquele limite que eu tinha para gastar
dentro daquele consentimento então eu
faço um pagamento verifico se se
continua em authorized né Então essa
aqui é uma diferença de lógica com
relativa as APS de pagamento repito o
processo Então faço um segundo pagamento
de 300 dois pagamentos de 300 com limite
de 600 ele eh vence o consentimento aqui
né E aí eu dou um eh eu eu verifico o
consentimento depois verifico se agora
sim né ele foi para consumed e dou um
Get No naquele segundo end Point né
então a gente tem dois end points hoje
né um que é o get recr payments com
recruit payment ID Então esse aqui é
para verificar o estado de um pagamento
e aí depois eu dou um Get No recru
payments passando o recru Constant ID no
header e aqui eu tenho que retornar
lista de todos os pagamentos feitos
então aqui a gente vai chamar os dois né
a gente no início chama um get recing
payments para um pagamento específico E
aí depois a gente dá um get pro
consentimento e espera que retorne a
lista com os dois pagamentos de 300 que
a gente fez né então basicamente um
cenário feliz aqui passando por todos os
ent points aqui vai ter aquela
característica ali que eu comentei do
dos do do CPF né o CPF que a gente vai
usar tá aqui se você informar na
configuração a gente vai usar esse no
creditor se você não informar a gente
vai usar isso aqui no log de user Então
é só pra gente ter certeza de que o log
de user igual creditor aqui Seguindo
aqui account limits né Ach que esse aqui
é o maior test que a gente tem ele é
basicamente testar todos os limites que
existem dentro da api dentro do
consentimento Então a gente vai criar um
consentimento com algumas valores ali
depois a gente começa a brincar assim
digamos com vários tipos de pagamentos
diferentes quantidades etc a gente vai
fazer um post vai fazer um um
consentimento né Eh mandando transaction
limit 400 Então posso fazer o máximo que
eu posso fazer por transação é 400 eh no
dia eu posso fazer r$ 500 e no dia eu
posso fazer duas transferências E aí
baseado nisso né a gente redireciona o
usuário autoriza o consentimento eu faço
uma primeira chamada com 450 então isso
aqui deve ser barrado pelo transaction
limite de 400 né já que o o limite de
transação que eu posso fazer é 400 Tô
fazendo um pagamento de 450 ISS é
barrado e aí a mensagem de erro que o
Gustavo comentou também limite período
valor excedido isso tem que ser
retornada depois eu dou faço um
pagamento com 300 isso é aceito aí Aqui
um ponto importante também né que o a a
a a conta do limite né então a gente tá
falando que eu posso fazer dois
pagamentos por dia são dois pagamentos
com sucesso então quando eu faço um
pagamento que não tem sucesso isso não
entra nessa conta de dois né então a
gente verifica isso aqui também eh chama
post cing end Point né com 300 validado
vej se pagamento foi feito faço um
segundo com 300 agora meu limite diária
é 500 Então já fiz um pagamento de 300
se eu fizer outro esbarra nesse limite
Então espera um 422 eh e aí depois eu
faço um de 100 e aí como é 400 ele vai
tá dentro aqui verificao se o pagamento
foi feito E aí depois eu faço mais um
pagamento de 50 Então eu tenho um limite
Diário de 500 eu fiz um pagamento de 300
um de 100 e o terceiro de 50 apesar de
tá dentro do limite diário ele tá fora
do limite de quantidade porque eu só
posso fazer dois pagamentos por dia
então a gente espera que aqui seja um
limite período quantidade excedido então
a gente testou aqui o limite o limite
por transação o limite de periódico né
total e também o limite de quantidade
Total então a gente aqui basicamente é
um módulo pra gente testar todos esses
cenários diferentes seria de limites eh
na sequência a gente tem alguns testes
relativos a creditor Então a gente tem
eh esse wrong creditor né a gente vai
basicamente faz um cria um consentimento
coerente né cria um um consentimento
correto e na hora de fazer o pagamento
eu mando um crédit diferente só para ver
se tá sendo feita a validação do
creditor do pagamento se esse creditor
tá dentro do da da aray lá de de de
créditos passados no consentimento né
então cenário infeliz aqui eh depois é
negative conant É um cenário infeliz
também onde a gente vai testar vários
várias validações síncronas no post
conant né a primeira a gente não manda
um campo do recr configuration espera um
422 Já que é um campo obrigatório eh
segundo a gente faz foi o o o o cenário
que o que o que o Zé comentou aqui a
gente passa um start date time de D + 10
então ele vai começar daqui a a 10 dias
só que ele expira em cinco então não tem
validade né o consentimento porque o
início é depois do fim então a gente
espera um 422 também e por última
questão do X fap interaction ID a gente
vai mandar um request sem o x fap
interaction ID vai esperar um 400 e
espera que um X fap interaction ID seja
gerado e retornado Então a gente vai
fazer essa verificação aqui
basicamente na sequência um teste pra
gente verificar a questão da matri da da
Matriz do CNPJ né então eu posso mandar
em casos de CNPJ nem em casos de de de
PJ eu posso mandar vários creditors como
CNPJ o ponto aqui né É que esse CNPJ ele
precisa até a mesma Matriz is Então os
oito primeiros dígitos precisam ser
iguais que a gente faz aqui é
basicamente isso né eu crio um
consentimento com quatro e CNPJ e Iguais
ali iguais não né com a mesma Matriz
então todos os participantes da mesma da
mesma empresa verifico o 201 faço
pagamento para um faço pagamento para
outro veja se eu consigo fazer esse
pagamento por esses dois créditos
diferentes na sequência é um é um CNPJ
inválido então eu crio um consentimento
com um CNPJ inválido Ou seja eu mando
dois CNPJ que não tem a mesma raiz
espero que isso seja negado também e por
último aqui os testes de web Hook então
é basicamente é bem parecido com os
cenários que a gente já comentou ali em
cima e E aí eu acho que mais fácil até
vir pra máquina de estado aqui né pra
gente ver que que a gente tá testando
basicamente os cenários de web Hook que
são são possíveis aqui para sweeping
accounts Então a gente
tem pagamentos automáticos aqui então a
gente tem um teste que a gente vai
testar tá PR m para múltiplas alçadas né
se o Web Hook é enviado quando passa de
par el accepted para authorized Então
esse é um teste de web Hook o segundo se
eu consumir o consentimento Eu recebo um
web Hook esse é outro teste e aí esse
aqui esse teste tá junto com verificar
se eu recebo um webhook quando o
pagamento foi feito então esse é o
segundo teste webhook terceiro revoked
então eu crio um consentimento autorizo
revogo verifico se chega um we Hook e o
quarto rejeitado né então eu crio um
consentimento em authorization chama o
pet verifico se ele foi rejeitado E aí
eh espera um webhook também né então são
quatro cenários de webhook que vão estar
todos dentro do mesmo plano
eh que são esses quatro últimos aqui né
multiple consents revoked rejected e
aceito né que aí verifica também o
estado consumo de consentimento Então
pessoal em resumo era isso né como eu
comentei só recapitulando a gente vai
ter lançamento de três testes hoje a
Fabia vai falar aqui um pouco sobre os
Marcos no dia 22 a gente tem um
lançamento de mais 14 eh E aí tudo a
gente vai est atualizando ali dentro do
release Notes acompanhar também pelos
sítios do gitlab E aí qualquer dúvida
que tiver também manda o ticket pra
gente que a gente tem aqui pelo cara
aqui para poder tirar dúvidas e tudo
mais ali mas é acho que é basicamente
isso
febi obrigado
pessoal Cris Muitíssimo obrigada
eh pessoal aqui tá dando mais ou menos o
nosso horário então vou passar rapidinho
aqui por essa última parte tá então
agradecendo de novo aqui a presença de
todo mundo eh então o que que é esperado
das instituições né assim Resumindo tudo
isso quais são os próximos passos depois
de tudo isso que a gente passou hoje né
então boa parte aqui da apresentação é
bem semelhante com a que a gente teve de
pagamentos eh pagamentos recorrentes
Então vou dar uma resumida tá então aqui
a gente tem um ecossistema que ele ele
tem que ser colaborativo né então tem
uma parte de eh obtenção da maturidade
tanto itens da das especificações como
questão do motor então por isso que a
gente tem os Marcos e é importante toda
a quanto antes As instituições
identificarem pontos de correção ou de
melhoria notificarem mais tempo de
reação a gente tem para fazer as devidas
correções ajustes melhorias isso também
significa mais tempo para vocês o lado
das instituições conseguirem incorporar
essas mudanças tá então
eh aqui eu vou vou pular essa parte que
ela é bem parecida o único ponto de
atenção é o motor ele pode ter mudanças
ao longo desse processo que elas são
mais ou menos restritivas então mais
restritivas é quando o comportamento que
tava sendo aceito antes ele deixa de ser
aceito então a gente estava esperando um
código de erro por exemplo e agora esse
código de erro mudou então um campo que
ele era opcional ele se torna
obrigatório então quando a gente tem
essa mudança mais restritiva a gente
torna a gente fala que é uma Breaking
Change E aí todo mundo tem que re
executar tá o motor Depois dessa mudança
e assim que ela for identificada a gente
vai notificando as instituições então
tem tanta página ali do Breaking Change
Quanto quanto a gente vai mandando em
forma para vocês eh Essa vai ser uma
certificação que ela vai ser de maneira
regular Então ela também vai ter o
processo de abertura de Ticket da
maneira tradicional como a gente já tem
eh então assim que que chegar o período
Quando a gente tiver o a versão madura
das especificações versão estável das
especificações e do motor aí Executa os
testes nessa última versão abre o ticket
no service desk passa pelo processamento
depois a publicação eh do end dos end
points ali no diretório produtivo e aí
mais detalhes sobre como exatamente vai
ser essa parte operacional de publicação
de golive a gente entra em detalhes mais
perto dessa dessa data e aí ponto de
atenção é retomando aqui todo mundo
precisa ter o fap único para entrar em
produção de transferências inteligentes
então reforçando o que a gente falou no
workshop de terça-feira fundamental que
vocês vão vão desenvolvendo aí também o
perfil único FAP em paralelo porque não
adianta um entrar em produção o outro
não tá então os cronogramas estão bem
casados então reforçando aqui essa essa
dependência O que que a gente vai ter de
cronograma aqui então tá primeira parte
do motor ela tá sendo
disponibilizada hoje
e aqui no dia 8 e a gente teve uma aqui
nas especificações com que um dos Testes
que era o que a gente tava recomendando
vi até que a Jaqueline mandou a dúvida
um dos Testes que a gente estava
recomendando
ele ele tá desatualizado tá então por
isso que ele não vai mais sair então na
data de hoje a gente vai disponibilizar
três testes o informe vai sair hoje ao
longo do dia e aí desses três testes a
gente recomenda execução desses dois que
eles também não dependem da jornada de
ux então desses três testes a gente
recomenda eh você as instituições vão
ter que que passar em um deles até o dia
15 e o E aí a gente recomenda que seja
um desses dois tá se quiser passar no
terceiro teste também não tem problema
tem só um risco de de retrabalho porque
esse terceiro teste ele já depende da
jornada de iex tá então acho que esses
são os pontos principais aqui só
reforçando a gente vai ter o Marco a que
é essa execução com sucesso de um teste
na sexta-feira que vem e depois o
próximo Marco As instituições vão ter
que passar em 40% dos Testes que a gente
tava 40% dos Testes que a gente divulgou
no dia 10 de janeiro
eh e
75% no dia 29 de Janeiro e passando em
todos os testes até o dia 19 de
Fevereiro e aí só pedindo atenção aqui
para vocês a gente sabe que aqui vai ter
essa certificação Ela vai passar tanto
por Natal quanto ano novo quanto pelo
carnaval então só dá uma olhadinha aí
como vai tá a locação de equipe a a
gente tentou levar isso em consideração
na no desenho do cronograma então alguns
períodos aqui que a gente costuma deixar
duas semanas a gente deixou um pouquinho
a mais onde dava eh para tentar
incorporar esse esses períodos que são
um pouco mais eh complicados de de
férias coletivas mas aí peço que vocês
já já consigam se planejar para não
correr para não arriscar o atendimento
algum dos Marcos
tá E aí pessoal Acabei de ver aqui eu
vou pedir mil desculpas acho que esse
cron que eu peguei ele tá desatualizado
a gente atualiza pra versão final mas
aqui a gente tem parte dos Testes S
disponibilizados hoje e a segunda parte
ele vai ficar pro dia 22 de janeiro de
Dezembro tá então aqui eu vou vou
atualizar mas aqui tá confirmado que
esses três primeiros testes vão est vão
ser divulgados hoje
tá então aqui tem uma parte com links
que a gente vai divulgar para vocês
também com ações interessantes
basicamente página do portal do
desenvolvedor com as especificações das
apis o calendário página de inform
releas Notes que é a página que o
chistian tava mostrando agora o portal
do desenvolvedor ali o sweger que o que
o Zé tava mostrando tem o Git para
abertura de tickets sobre o motor com
problemas ali service desk para dúvidas
Gerais ali da instituição dúvidas sobre
especificações a estamos trabalhando
aqui coletivamente dentro da estrutura
para atender todas as demandas aqui o
de a maneira mais rápida possível Aí
queria ver aqui temos algumas dúvidas no
chat a gente já passou do nosso horário
mas acho que a gente pode
eh não sei se a gente tenta passar por
alguma senão o restante a gente pode Vou
sugerir aqui CCO minutinhos de dúvidas a
gente pode ficar até
11:45 E aí o restante que foi enviado no
chat a gente tá consolidando colocando
as respostas e aí a gente vai divulgar
todos os materiais
em paralelo acabei vou mandar aqui para
vocês um formulário com pedindo feedback
para vocês tanto do do workshop de hoje
quanto dos outros que a gente já teve
peço aqui que vocês coloquem se sentiram
falta de alguma informação que vocês
estão achando qualquer que a gente já
consegue até melhorar aqui o fluxo do
dos workshops pro de segunda e de
terça-feira tá então muito importante
aqui essa essa visão de vocês a gente tá
aqui para tentar atender o ecossistema
aí vi aqui que o Jorge levantou a mão Ah
não desculpa tá a mãozinha do Maurício
por
favor Opa bom dia a minha pergunta Acho
que não foi totalmente Eu não entendi a
resposta não foi totalmente respondido a
partir de grandes volumes tá eh porque
eu sempre trabalhei com pessoa jurídica
e esse é sempre foi nosso calcanhar de
aqui a gente pensa que é pouca coisa mas
daí começa a aparecer a exceção né Eu
concordo que po ser uma exceção Mas pode
aparecer como a data não é limitada no
detentor pode vir aí um período de 2
anos e Suponha que tenha duas transações
por dia é um volume razoável para
recuperar e devolver então o que como
que foi pensado nisso e pessoa jurídica
a gente sabe tem pode acontecer não sei
se é o caso aqui é ter transações 10.000
transações num dia 20.000 30.000 num dia
então não sei se vai chegar nesse volume
provavelmente não né Mas se chegar né
que nosso que a gente quer que como é
que a gente vai tratar isso sendo que
essa essa consulta que eu perguntei lá é
de forma assíncrona né seria
praticamente inviável devolver tudo
isso
eh deixa eu começar aqui tá Vou vou
iniciar aqui talvez
a respondendo mas aí o o Zé pessoal aqui
eu acho que eles podem também me
ajudando Mas respondendo aqui tá que que
acontece né a ideia aqui do da
transferência inteligente é que eh os
limites eles são feitos Ou eles
eh a gente a gente não não parametriza
nenhum tipo de limite dentro da da da do
fluxo hoje eh qualquer limitador de de
do recurso Ele tá seguindo os trilhos do
arranjo no qual se encontra que é o pit
Então se hoje você tem
um um validador dentro da sua
instituição sobre quais movimentações
quais do volumes que podem ser feitos
Essa é a regra que ela deve seguir deve
permanecer a gente não preferiu não
trazer isso para dentro da aqui dentro
do da nossas da feature assim assim como
eu vou colocar para não
eh gerar mais nenhuma trava ou impactar
mais
eh questões aqui em cima desse dessa
dessa solicitação entendeu já foi até
ponto de discussão dentro do próprio GT
também w posso complementar por favor
pesso um pequeno probleminha na minha
câmera não vou conseguir abrir aqui tá
mas
eh Maurício a gente tem o mecanismo de
paginação né dentro da api hoje eu acho
se eu entendi bem a sua pergunta você tá
preocupado mesmo é com o tamanho da
resposta né que você vai precisar
devolver né
Eh acho que a gente vai ter que melhorar
os mecanismos de paginação dentro da api
tá a gente não chegou a discutir esse
ponto ainda justamente porque você como
você mencionou eh É um cenário digamos
assim extremo né que a gente não não
acredita que tem uma grande
possibilidade de ocorrer Então acho que
o tratamento para esse cenário
específico ele ainda ficou pendente tá e
a gente precisa discutir se vamos adotar
os mecanismos de paginação como que vai
ser feita essa paginação qual o limite
máximo que vai ser retornado por página
e etc Tá mas isso não tá batido o
martelo ainda a gente não teve essa
discussão
perfeito e inclusive períodos tá porque
a gente vê assim ah mas tem duas dois
por dia tá bom agora não é problema mas
daqui é 5 anos se a gente não limitar
pode entrar um cliente e pedi 5 anos e
daí volta ter o problema de Altos
volumes Mas obrigado esclarecimento tá
nada desculpa eu tinha entendido outra
questão aqui Maurício Mas obrigado
Zé Jorge Jorge oi oi pessoal
primeiramente aí parabéns pela
apresentação Eh o meu comentário é sobre
o item do cronograma pilotos e testes
adicionais né visto que em fases
anteriores A gente não teve essa
situação só para entender que é esperado
nessa fase né que são esses pilotos que
estão eloc obrando dentro desse período
de dois meses após testes e pré go Live
né até pra gente se planejar aqui dentro
das nossas atividades aqui são duas
semanas né ô desculpa aqui na 25 de
Março a 14 de abril foi mal 25 de Março
imagina Jorge vamos lá o que que
acontece aqui Tá esse período ele vai
ser o mesmo da execução do dcm para
entrada em produção do fap único tá
então aqui a gente vai ter a
certificação ocorrendo até o dia 19/03 a
gente vai emitir as certificações só que
esse período aqui do dia 25 até o dia 14
é quando o foco das instituições tem que
ser fazer o dcm para o perfil fap único
e aí para entrada em produção eh do
pagamento automático As instituições vão
ter fazer mais um dcm então se você já
tiver pronto na sua instituição você
quiser se adiantar aqui nesse período
fez o dcm pro fap único quer fazer mais
um dcm para testar com uma outra
instituição já o o o pagamento
eh as transferências inteligentes você
já pode fazer Tá então não vai ter se
quiser fazer algo bilateral nesse
período Então fez o fap fez o dcm pro
fap único quer fazer um outro dcm fazer
um teste bilateral você tem autorização
porque você já vai estar certificado né
já vai ter obtido todas as certificações
aqui necessárias tá entendi porque tem
um novo um novo nova desculpa aí
envolvido né rec P beleza OK obrigado
exato E aí a gente não colocou eh a
gente tava com receio de colocar o mesmo
período para fazer todos os dcms eh com
receio de ter muita entrada entrada em
produção de muitas coisas diferentes no
mesmo dia alguma coisa quebrar e a gente
não consegui identificar a instituição
Não consegui identificar o que que
exatamente quebrou foi o fap único foi o
pagamento foi a transferência
inteligente foi o pagamento recorrente
então por isso que a gente tentou
segmentar aqui mas quem quiser se
adiantar ali fazer algum teste tá
liberado
não perfeito agradeço
imagina ótimo ponto aqui
tá pessoal acho que aqui
eh deu aqui o nosso o nosso horário eh
reforçar aqui o pedido para todo mundo
responder o o formulário aqui de de
avaliação doss workshops queria
agradecer de novo tanto os nossos
queridos apresentadores aqui então wend
Zé o breslin e e o Cris agradecer todo
mundo da estrutura aqui então
secretariado dto grupos técnicos que
estão todo mundo colocando aqui a mão na
massa para todos os nossos fornecedores
para colocar a mão na massa para tirar
isso do Papel eh e agradecer
participação aqui engajamento das
instituições qualquer dúvida que vocês
tiverem a gente tá à disposição tá vamos
em frente e espero encontrá-los na
segunda-feira
também valeu obrigada bom dia e bom
final de semana Obrigado pesso pessoal T
Tchau bom