07-26-2021 12:33 AM - edited 07-26-2021 12:34 AM
Let's consider one scenario:
According to this scenario, is the behavior of the last step is expected, or its an exception.
If this is expected, how can we cater to the requirement mentioned in the first step?
07-28-2021 12:47 AM
Hey @Arvind, good question. The Single Use Spend Control is a User level control so it’s acting as expected as it restricts the total amount of transactions per User not per Card. This is structured to be ’one card per user and as of right now I don’t believe we can restrict transactions at the card level.
Does this help?
07-28-2021 06:12 AM
Hey @Ricardo ,
Thanks for your response.
So, what should be the best way to implement the above requirement?
Is there anything planned for this in the pipeline?
07-28-2021 08:06 AM
Hey @Arvind, as with a lot of things in payments, the answer depends…so before I can provide some tips, could you give us more details on what you hope to accomplish with this use case? That will help me point you in the right direction to save you time.
08-03-2021 11:29 AM
As far as my knowledge goes, User1 would have to create a child user per gift card and each of those child users would need a single-use spend control. Any card product control applies across all cards created with that card product. I may be misunderstanding the question, but from what I know that would be the solution I would pursue.
08-05-2021 09:37 AM
The recommended way to implement a single-use card program is to leverage single-use-accounts. Each time you want to issue a new single-use card, you would first create a new user (GPA) that the card can be issued to. You would only issue one card per user, and you can use card-product-level velocity controls. Having parent/child users, or having user-level-velocity controls is not needed, though it is viable to implement in that way.