Return relevant fields for push to card in unauthenticated card tokenization

[matin]

Currently, only the href and id are returned when tokenizing without a secret key.

The following should also be returned on the Card:

1. can_credit
2. type
3. category
4. bank_name

[remear]

@matin All unauthenticated tokenizations return href and id by design in API 1.1.

{
    "cards": [
        {
            "href": "/cards/CC6jYBXR91ujWSkvnmPUmRy7",
            "id": "CC6jYBXR91ujWSkvnmPUmRy7",
            "links": {}
        }
    ],
    "links": {},
    "status_code": 201
}

{
    "bank_accounts": [
        {
            "href": "/bank_accounts/BA6rJZeYQYCWdz9sWNXQFOET",
            "id": "BA6rJZeYQYCWdz9sWNXQFOET",
            "links": {}
        }
    ],
    "links": {},
    "status_code": 201
}

Additional fields are returned after claiming the funding instrument to the marketplace. Why should these other fields be returned on tokenization (and only for a card?)?

[matin]

@remear it allows the customer to manage the logic client side. It's a similar reason to how balanced.js can check card number and routing number validity.

[msherry]

@matin those checks are just Luhn checks, though -- they're based on the structure of the card number itself. There's no way to do what you're proposing without calls to the backend server, which would change the way data is currently returned.

[matin]

@msherry We also check if the routing number is valid. If it's not valid, we don't tokenize, which means the customer doesn't need to have any server side logic.

There's no way to do what you're proposing without calls to the backend server, which would change the way data is currently returned.

I'm proposing Balanced makes changes to the fields we return to balanced.js, which I agree would require backend changes for us.

[msherry]

@matin Why do you want a subset of the useful fields returned at tokenization time, while I have to fetch the card to get the rest of them?

Or are you suggesting that we also return the result of the CVV/AVS checks at this time?

[jkwade]

@matin is there a specific customer in mind that has this use case? We've had customers ask for something similar in the past (specifically for last_four and type) and we've declined to change our behavior.

[matin]

I'm only trying solve the problem for push to card.

[msherry]

I guess I'm confused what problem this is solving. Is it to avoid tokenizing cards that can't be used for P2C? Why avoid tokenizing them? To avoid making an API call? We'd still have to make an API call to determine if they can be used in the first place, right?

[matin]

I created this issue based on feedback we had received from customers for push to card.

@msherry I agree that tokenization would happen, but the customer still would have the ability to instruct the cardholder to enter a different card if can_credit is false.

@jkwade

We've had customers ask for something similar in the past (specifically for last_four and type) and we've declined to change our behavior.

I believe there's another issue for that. I'm proposing type be returned as part of this issue. I'm less familiar with why last_four would be helpful in balanced.js. I suggest we keep that discussion to another issue since it doesn't relate to p2c.

[msherry]

What about bringing back the old behavior of, if a card is tokenized under /marketplaces/MPXXX/cards, then tokenization is immediate and the full Card resource is returned to balanced.js, rather than just an href that needs to be claimed? That solves the problem raised in this issue, avoids the state where some-but-not-all useful fields are returned, and (IMO) is more intuitive and understandable to customers.

It would also help to resolve a lot of issues like https://github.com/balanced/balanced-dashboard/issues/1201.

[mjallday]

@msherry it already does return the full resource if the request is authenticated. however no cli libraries support that since how do you keep the secret secure?

[msherry]

@mjallday in 1.0, the full resource was returned for unauthenticated POSTs to /marketplaces/MPXXX/cards -- I'm proposing bringing that back as an option for marketplaces who want this behavior.

[mjallday]

that's a boon for people looking to validate credit cards anonymously tho right? also allows you to tokenize cards on a marketplace you do not own

[msherry]

Sure, but in the real world that very rarely seemed to happen, in the time that we supported it (we still do, for 1.0). If a marketplace is worried about it, have a flag to disable/disallow this behavior for their marketplace. Since these POSTs are by definition namespaced to the mp, that's easy to do.

[msherry]

cf. https://dp.balancedpayments.com/#/marketplaces/MK2fb2e1069f6d11e1b897026ba7e239a9/logs/OHM5bf86cd495f811e4b58d02a1fe52a36c -- still supported.

[matin]

@msherry you're right that it makes sense to revisit that design decision. There are other ways to detect and block abuse.

@remear what caused you to visit this issue today?

[mahmoudimus]

lawl @msherry your'e reading too many academic papers (c.f.) :D

[remear]

@matin, pruning issues.