Elements com changelog da API Checkout SessionsVisualização pública
Acompanhe as alterações do Elements com a integração da API Checkout Sessions.
O Elements com a API Checkout Sessions usa dois tipos de versões beta:
- Um cabeçalho Stripe.js beta (por exemplo,
custom_
), definido na sua integração de frontend.checkout_ beta_ 5 - Um cabeçalho beta da versão da API (por exemplo,
custom_
), definido na sua integração de backend.checkout_ beta=v1
Versões beta do frontend
Especifique a versão beta do frontend ao inicializar o Stripe.js.
custom_checkout_beta_5
- Breaking A função
initCustomCheckout
foi renomeada para initCheckout- Dentro do React Stripe.js,
CustomCheckoutProvider
foi renomeado paraCheckoutProvider
useCustomCheckout
useCheckout
.
- Dentro do React Stripe.js,
- Breaking Para confirmar o Express Checkout Element, chame confirm, passando o evento confirm como
expressCheckoutConfirmEvent
- Anteriormente, o Express Checkout Element era confirmado chamando
event.
.confirm()
- Anteriormente, o Express Checkout Element era confirmado chamando
- Breaking Quando confirm é chamada, o Payment Element e o Address Element validam as entradas de formulário e processam os erros.
- Breaking As mensagens de erro foram padronizadas e aprimoradas.
- Os erros retornados/resolvidos por uma função representam cenários conhecidos, como dados de pagamento inválidos ou fundos insuficientes. Esses são problemas previsíveis, que podem ser comunicados ao cliente exibindo a
message
na página de checkout. - Erros lançados/rejeitados por uma função representam erros na própria integração, como parâmetros ou configuração inválidos. Esses erros não devem ser exibidos aos clientes.
- Os erros retornados/resolvidos por uma função representam cenários conhecidos, como dados de pagamento inválidos ou fundos insuficientes. Esses são problemas previsíveis, que podem ser comunicados ao cliente exibindo a
- Breaking Métodos assíncronos, como confirm ou applyPromotionCode, são resolvidos com um esquema diferente:
- Um campo discriminador
type="success"|"error"
foi adicionado. - Se for bem-sucedido, o estado da sessão atualizada será preenchido sob a chave
success
. Anteriormente, isso estava sob a chavesession
. - Caso contrário, o erro continuará a ser preenchido sob a chave
error
.
- Um campo discriminador
- Adicionadas as opções
email
,phoneNumber
,billingAddress
eshippingAddress
para confirma. - O Breaking Address Element não atualiza mais automaticamente os campos billingAddress ou shippingAddress na sessão.
- Desde que o Address Element esteja montado, os valores de formulário serão usados automaticamente ao chamar confirm
- Escute o evento change para usar o valor do Address Element antes da confirmação.
custom_checkout_beta_4
- Imagens adicionadas ao objeto Session.
- Campos adicionados como opção ao criar o Payment Element.
- PaymentMethods adicionado como opção ao criar o Express Checkout Element.
- Breaking Passar opções inválidas para createElement agora gera um erro. Anteriormente, opções não reconhecidas eram ignoradas silenciosamente.
- Breaking updateEmail e updatePhoneNumber aplicam alterações de forma assíncrona. Chamar esses métodos antes que o cliente termine de inserir valores completos pode causar baixo desempenho.
- Em vez de chamar
updateEmail
ouupdatePhoneNumber
no evento de alteração de cada entrada, aguarde até que o cliente conclua a entrada, como no desfoque da entrada ou quando envia o formulário para pagamento. updateEmail
agora, valida se a entrada é um endereço de e-mail formado corretamente e retorna um erro se uma entrada inválida for usada.updatePhoneNumber
ainda não executa nenhuma validação na cadeia de caracteres de entrada.
- Em vez de chamar
custom_checkout_beta_3
- Os seguintes campos foram adicionados ao objeto Session:
- Cartões salvos agora podem ser reutilizados. Saiba como salvar e reutilizar formas de pagamento.
- Breaking O layout padrão do Payment Element foi alterado para
accordion
.- Para continuar usando o layout padrão anterior, você deve especificar
layout='tabs'
explicitamente.
- Para continuar usando o layout padrão anterior, você deve especificar
- Breaking O comportamento padrão de confirm foi alterado para sempre redirecionar para o após
return_
uma confirmação bem-sucedida.url - Anteriormente,
confirm
era redirecionado somente se o cliente escolhesse uma forma de pagamento baseada em redirecionamento. Para continuar usando o comportamento antigo, passe redirect=‘if_required’ paraconfirm
.
- Anteriormente,
custom_checkout_beta_2
- Breaking O campo
lineItem.
foi removido e substituído por lineItem.recurring.intervalCount.recurring. interval_ count - Breaking O campo
lineItem.
foi removido e substituído pelo seguinte:amount
custom_checkout_beta_1
Esta é a versão beta inicial do frontend.
Changelog do backend
Especifique a versão beta do backend quando configurar a biblioteca do servidor.
Não há alterações na versão beta do backend.