Repository navigation
PHPAY-173: feat: billets everywhere they exist, cards where the number fits - #177
Closed
mariolucasdev wants to merge 1 commit into
Closed
mariolucasdev wants to merge 1 commit into
mariolucasdev wants to merge 1 commit into
Conversation
…r fits boleto() and credito() finish the portable path on all ten gateways, and Card describes a card for the two that take the number on the server. Card cannot cover every gateway, and pretending otherwise would be the lie: the Cielo and the Rede take the number, but the Mercado Pago takes a token minted by its own browser SDK, so the number never reaches the server at all, and the PagBank and the Pagar.me want it encrypted or tokenized. Those simply do not declare CREDIT_CARD, which is what supportedMethods() is for. The number is checked with Luhn before any request, because a wrong digit costs nothing here and a refusal on someone's checkout there. The number and the CVV take SensitiveParameter and never reach a dump. The brand is not derived from the number range: the Cielo requires it and guessing would be the library inventing a fact about the card. Debit is absent from all ten. The Cielo and the Pagar.me know the type, but it needs 3DS authentication, which the library does not model, and declaring a method the call would refuse is the mistake this capability was built to avoid. On the Efi the portable path does billets, not Pix: charge() there IS the billet and the Pix charge is pixCharge(), on another API, so routing Pix would change what charge() returns and break the v2.
Collaborator
Author
|
Fechado pelo GitHub quando a branch da fase 2 foi apagada no merge do #176 — PR cujo branch-base some é fechado automaticamente, e não reabre. Erro de ordem meu: o reapontamento para Continua em #178, com a mesma branch já rebaseada ( |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fase 3 de #173. Empilhado sobre o #176 — a base é
feat/phpay-173-fase2,então mergeie o #176 primeiro. Como o merge é squash, eu preciso rebasear este
com
--ontodepois; o botão "reaponta sozinho" não serve aqui.Começo pelo que mudou de premissa
A fase 3 era "
boleto(),cartao(),Carde os gateways que faltam". Ao lercomo cada um recebe cartão, o
cartao()universal se mostrou impossível,não só trabalhoso:
Card?Payment.CreditCardEntão entregue:
Cardpara os dois que recebem o número, e os outros nãodeclaram
CREDIT_CARD. É exatamente o caso de uso que osupportedMethods()da fase 1 existe para cobrir.
O que entra
PHPay\Support\CardChargeIntent::boleto()ChargeIntent::credito()Carde parcelasOs dez declaram a capacidade agora. A Cielo faz os três meios; a Rede, que
só faz crédito, entra pela primeira vez no caminho portável.
O
Carde o PANpego aqui e custa uma recusa no checkout de alguém se for pego no gateway.
#[\SensitiveParameter]no número e no CVV, e__debugInfo()devolve**** **** **** 1111e***. Tem teste provando queprint_rnão vaza nenhum dos dois.número seria a biblioteca inventando um fato sobre o cartão. Sem ela, recusa
antes de qualquer HTTP.
Débito ficou de fora, de propósito
Cielo e Pagar.me conhecem
DebitCard/debit_card, mas débito pedeautenticação 3DS, que a biblioteca não modela. Nenhum dos dez declara
Method::DEBIT_CARD, e há teste varrendo isso — declarar um meio que a chamadarecusaria é o erro que esta capacidade foi feita para evitar.
A Efí faz boleto, não Pix
Lá
charge()é o boleto e o Pix épixCharge(), noutra API. Rotear Pixmudaria o retorno de
charge()e quebraria a v2 — entãosupportedMethods()dela diz
BOLETO, e a mensagem de recusa do Pix diz isso a quem tentar.Uma consequência que quebrou um teste, e o conserto é melhor que o original
Com os dez declarando a capacidade, não sobrou gateway para provar a recusa
da facade. O teste passou a usar um gateway anônimo que implementa só
SupportsCharges— o que é mais correto, porque quem está sendo testado é oguard da facade, não um gateway específico.
Dois tropeços meus que valem registro
['appId' =>virou['appId' =>), e minha substituição por texto exato falhou emsilêncio porque ali eu não tinha posto
assert. Refiz por intervalo delinhas. A lição é a de sempre: substituição sem verificação não é edição, é
esperança.
esta fase tornou falso em quatro gateways. Passou a usar
DEBIT_CARD, quenenhum faz e cuja ausência já é afirmada noutro teste.
Portão
createCharge()O que fica aberto na #173
Não é gateway, é meio: cartão nos que pedem token ou blob cifrado e
débito em qualquer um. Os dois precisam de desenho próprio — para o cartão,
provavelmente um
CardTokenao lado doCard; para o débito, 3DS. Nenhum dosdois é "mais um
fromIntent()".