Add support for gift card with SKU 18732 #349
Comments
|
What's so special about this specific product and why would we need to allocate 4 hours of work just to add a single extra card? Don't we already have hundreds of options? |
Previous fallback mastercared SKU 18597 and this new SKU 18732, both support the same list of 139 countries. The special thing about this card is that it is now 2nd mastercard in the Reloadly list, which supports the full Mastercard supported countries list. This new SKU 18732 can be used as a second fallback card. Moreover, it appears reloadly is replacing old-18597 with new-18732. Or at least it is the situation for now. Because the reloadly dashboard is also offering new-18732, and I don't see old-18597 on their dashboard anymore. It could also be a temporary out of stock problem. I will ask them in chat and will update here. |
|
@EresDev Help Right now Do you think implementing current github task could help? |
The old fallback cards 18597 or 18593 should be available to South Korea. But I haven't seen them being available at all in the last few times I checked. Adding this new card 18732 as the first fallback card will be very helpful. @rndquu |
It seems that SKU 18597 is no longer supported because reloadly API returns the Anyway the new SKU 18732 seems to be available in South Korea so it makes sense to add support for it. @EresDev Could you make a priority for this task? Also pls set the time estimate. |
Yes please focus on implementing because I can't demo this conveniently where I'm based. It could be really interesting to do some automated tests using proxies to see if major cities are covered? At least where the conferences we plan to attend are. |
Gift cards are grouped by countries. If a particular city is in the country from this list SKU_ 18732 - Countries covered (5).xlsx then gift card with SKU 18732 should work there. |
Sure. The UbiquityOS has become aggressive recently :D and it might unassign me from the other task, but I am going to work on this anyway.
We have a decent set of tests. We do need to improve the e2e tests. But the suggested use case still needs more manual preparation. A gift card that is available now in tests or in a manual preparation might be out of stock/unavailable in the next hour. I have seen this happening. So for every presentation you need to prepare a series of backups for the presentation.
Many parts are out of control here for us, and probably even out of control of Reloadly. Redeeming, and probably even the minting also happens at a different service. So, more manual preparation should help. |
The unavailability of a card is mostly not a bug. So, it doesn't need tests. However, I understand that you want to have monitoring for the payment cards. And if we have that, you probably will not be able to redeem cards that you bought for different locations. So, manual preparation still seems more useful to me. |
I don't know what "manual preparation" means |
Have a plan B for the demo because gift card with sku 18732 (supported in South Korea) might be out of stock occasionally. In that case the simplest option is to use USA/Canada VPN. |
|
If this system doesn't work does that mean we need to use another card provider? |
If reloadly stops providing cards available in South Korea and we consider that a critical issue then, yes, we need to find another card provider |
|
/start |
|
With this card, I see they also have added a new required field in the card minting request. It is userId. I am going to use user's wallet address for this. |
|
For reference some conferences we are likely to see:
|
All countries are supported |
+ Evaluating results. Please wait... |
|
| View | Contribution | Count | Reward |
|---|---|---|---|
| Issue | Comment | 5 | 27.813 |
| Review | Comment | 1 | 15 |
Conversation Incentives
| Comment | Formatting | Relevance | Priority | Reward |
|---|---|---|---|---|
What's so special about this specific product and why would we n… | 2content:
content:
p:
score: 0
elementCount: 1
result: 0
regex:
wordCount: 34
wordValue: 0.1
result: 2
| 0.5 | 3 | 3 |
Yes please focus on implementing because I can't demo this conve… | 2.54content:
content:
p:
score: 0
elementCount: 1
result: 0
regex:
wordCount: 45
wordValue: 0.1
result: 2.54
| 0.7 | 3 | 5.334 |
I don't know what "manual preparation" means | 0.59content:
content:
p:
score: 0
elementCount: 1
result: 0
regex:
wordCount: 8
wordValue: 0.1
result: 0.59
| 0.3 | 3 | 0.531 |
If this system doesn't work does that mean we need to use anothe… | 1.06content:
content:
p:
score: 0
elementCount: 1
result: 0
regex:
wordCount: 16
wordValue: 0.1
result: 1.06
| 0.6 | 3 | 1.908 |
For reference some conferences we are likely to see:- eth denve… | 6.7content:
content:
p:
score: 0
elementCount: 1
ul:
score: 1
elementCount: 1
li:
score: 0.5
elementCount: 8
result: 5
regex:
wordCount: 28
wordValue: 0.1
result: 1.7
| 0.4 | 3 | 17.04 |
- Consensus HK (Hong Kong)… | 0.32content:
content:
p:
score: 0
elementCount: 1
result: 0
regex:
wordCount: 4
wordValue: 0.1
result: 0.32
| 0.7 | 3 | 0.672 |
Works fine, South Korea is covered now | 0.52content:
content:
p:
score: 0
elementCount: 1
result: 0
regex:
wordCount: 7
wordValue: 0.1
result: 0.52
| 0.7 | 3 | 1.092 |
Cloudflare deployment previews work in reloadly sandbox environm… | 1.85content:
content:
p:
score: 0
elementCount: 1
result: 0
regex:
wordCount: 31
wordValue: 0.1
result: 1.85
| 0.5 | 3 | 2.775 |
+ Evaluating results. Please wait... |
|
| View | Contribution | Count | Reward |
|---|---|---|---|
| Issue | Task | 1 | 150 |
| Issue | Comment | 5 | 0 |
| Review | Comment | 1 | 0 |
Conversation Incentives
| Comment | Formatting | Relevance | Priority | Reward |
|---|---|---|---|---|
Previous fallback mastercared SKU 18597 and this new SKU 18732, … | 0content:
content:
p:
score: 0
elementCount: 3
result: 0
regex:
wordCount: 115
wordValue: 0
result: 0
| 1 | 3 | 0 |
The old fallback cards 18597 or 18593 should be available to Sou… | 0content:
content:
p:
score: 0
elementCount: 1
result: 0
regex:
wordCount: 45
wordValue: 0
result: 0
| 1 | 3 | 0 |
Sure. The UbiquityOS has become aggressive recently :D and it mi… | 3content:
content:
p:
score: 0
elementCount: 7
ul:
score: 1
elementCount: 1
li:
score: 0.5
elementCount: 4
result: 3
regex:
wordCount: 189
wordValue: 0
result: 0
| 0.8 | 3 | 0 |
The unavailability of a card is mostly not a bug. So, it doesn't… | 0content:
content:
p:
score: 0
elementCount: 1
result: 0
regex:
wordCount: 58
wordValue: 0
result: 0
| 0.6 | 3 | 0 |
With this card, I see they also have added a new required field … | 5content:
content:
p:
score: 0
elementCount: 2
img:
score: 5
elementCount: 1
result: 5
regex:
wordCount: 32
wordValue: 0
result: 0
| 0.9 | 3 | 0 |
Resolves #349Other than the addition of the new mastercard 187… | 24.5content:
content:
p:
score: 0
elementCount: 13
ul:
score: 1
elementCount: 2
li:
score: 0.5
elementCount: 7
h2:
score: 1
elementCount: 1
h3:
score: 1
elementCount: 1
h4:
score: 1
elementCount: 2
img:
score: 5
elementCount: 2
a:
score: 5
elementCount: 1
result: 24.5
regex:
wordCount: 176
wordValue: 0
result: 0
| 0.9 | 3 | 0 |
[ 42.723 UUSD ]
@0x4007
Contributions Overview
| View | Contribution | Count | Reward |
|---|---|---|---|
| Issue | Comment | 5 | 27.723 |
| Review | Comment | 1 | 15 |
Conversation Incentives
| Comment | Formatting | Relevance | Priority | Reward |
|---|---|---|---|---|
What's so special about this specific product and why would we n… | 2content:
content:
p:
score: 0
elementCount: 1
result: 0
regex:
wordCount: 34
wordValue: 0.1
result: 2
| 0.4 | 3 | 2.4 |
Yes please focus on implementing because I can't demo this conve… | 2.54content:
content:
p:
score: 0
elementCount: 1
result: 0
regex:
wordCount: 45
wordValue: 0.1
result: 2.54
| 0.7 | 3 | 5.334 |
I don't know what "manual preparation" means | 0.59content:
content:
p:
score: 0
elementCount: 1
result: 0
regex:
wordCount: 8
wordValue: 0.1
result: 0.59
| 0.3 | 3 | 0.531 |
If this system doesn't work does that mean we need to use anothe… | 1.06content:
content:
p:
score: 0
elementCount: 1
result: 0
regex:
wordCount: 16
wordValue: 0.1
result: 1.06
| 0.6 | 3 | 1.908 |
For reference some conferences we are likely to see:- eth denve… | 6.7content:
content:
p:
score: 0
elementCount: 1
ul:
score: 1
elementCount: 1
li:
score: 0.5
elementCount: 8
result: 5
regex:
wordCount: 28
wordValue: 0.1
result: 1.7
| 0.5 | 3 | 17.55 |
- Consensus HK (Hong Kong)… | 0.32content:
content:
p:
score: 0
elementCount: 1
result: 0
regex:
wordCount: 4
wordValue: 0.1
result: 0.32
| 0.5 | 3 | 0.48 |
Works fine, South Korea is covered now | 0.52content:
content:
p:
score: 0
elementCount: 1
result: 0
regex:
wordCount: 7
wordValue: 0.1
result: 0.52
| 0.7 | 3 | 1.092 |
Cloudflare deployment previews work in reloadly sandbox environm… | 1.85content:
content:
p:
score: 0
elementCount: 1
result: 0
regex:
wordCount: 31
wordValue: 0.1
result: 1.85
| 0.8 | 3 | 4.44 |
|
@gentlementlegen I am leaning towards that rewards should always be limited even if there is no assignee? I can't think of a scenario where we would need no limits with no assignees. Also as a side note, I think that it would be nice to add the comment incentive for the pull body as well. So in theory the max rewards for an assignee could be 3x the limit (spec, pull body, task) @rndquu if I invalidate the Do you think you can work on a comprehensive plan to make UUSD cash outs more convenient? We should be slowly migrating all of our payouts to it but as I understand there are still some hoops to jump through making it confusing for contributors. South Korea QA: 
|
|
The non-assignee scenario was changed dunno if I merged it to the main branch. Sure can be changed, at the moment the cap is at 2x the reward (spec + reward) |
We should probably make this configurable. I'm assuming I can target pull body with |
Normalized rewards and added credit for pull body based on #349 (comment)
Normalized rewards and added credit for pull body based on ubiquity/pay.ubq.fi#349 (comment)
No, if this one is invalidated (for a particular user) then the latest one is also invalidated (only for a particular user) because permit nonce is based on github issue id.
Can't claim, as expected.
I don't fully understand what're the main pain points.
|
|
Perhaps we should research a more precise revocation strategy. I know keyrxng made a proposal about how they don't want to receive payouts in UUSD until it's more convenient to cash out with. Surely 1. they aren't the only one who feels this way 2. there's many aspects to solving this problem |
Payout tokens are totally up to a partner. Contributors can always swap whatever the reward token is to whatever is more convenient to cash out. |
I'm aware of this but our job is to make more people want to use our stable coin. There's a lot of aspects to this including making sure that it works on cowswap etc |
We have the feature of minting gift cards for crypto rewards which works this way:
pay.ubq.fichecks contributor's countryReloadly has recently added a new tokenized card SKU:
SKU_ 18732 - Countries covered (5).xlsx
It makes sense to support a new SKU 18732 this way:
pay.ubq.fichecks contributor's countrySo as a part of this issue we should make sure that SKU 18732 is supported in these pages:
Related comment.
The text was updated successfully, but these errors were encountered: