I am developing a new BEP-20 token which will replace an abandoned project. I want to give all current holders of the old token equal amount of the new token. My requirements are two
How to take snapshot of all the existing holders
How to airdrop them equal amount of new token.
Thanks in anticipation
Related
I am updating my billing page which used Stripe JS V2 tokens and the Charges API (Subscriptions). The new(er) Payment Element looks slick from a future proofing standpoint, but am I understanding it correctly that the Customer object must be created prior to populating the payment form?
I only create the Customer once the payment token is obtained and a user has a clear intent to purchase after evaluating during a trial period. Otherwise my Stripe Dashboard is overrun with "empty" trial users that never sign up (I only have around a 10% signup rate from account creation). I guess this is mostly just a personal peeve, but I also just don't like to share user data and figured this way I would only be sharing with a third party once they become actual customers of mine.
Since a Subscription cannot be created without providing a Customer as part of the required parameters, am I stuck using the Card Element and the older Charges API if I don't create a Customer for every user in my system?
You really should just create a Customer up front. It will be required if you want to use trials with Subscriptions and will be cleaner in the long run.
For a workaround, which I would not overall recommend, you could use a SetupIntent with Payment Element to collect the customer's payment method without actually creating a Customer object. Then you can later create the Customer object and attach the PaymentMethod that was previously collected and then create the Subscription.
I'm using Stripe Checkout. In all the documentation I can find, Stripe recommends saving Customer information (including a default Source) during my first transaction with that customer, and using that default Source later when I want to create subsequent Charges. However, if a customer uses a different credit card during a subsequent Checkout transaction, it would be a mistake to charge the default Source.
So, it seems like I should always just use the token from stripe.js when making subsequent changes, and that I should create a new source for the customer whenever I detect the them using a card that's different from the default source.
However, in my testing it appears as though every token I get from stripe.js represents a unique card, even if I've used the same credit card number, expiration, and CVC. If I were to create a new card for each Checkout token and save it to the customer record, I'd potentially end up with mounds of duplicate card records for each customer.
Am I overlooking a way to associate stripe.js tokens with customers in a way that doesn't generate duplicates? Or am I going about this incorrectly?
Whenever you collect card details in Checkout, Stripe will create a new token for that card even if they use the same card details. The Token resource has the fingerprint property though.
That property is a unique identifier for a given card number in your account. This means that if I sign up today with my card and then I come back tomorrow with the same card under a different email address you'd see the same exact fingerprint on both Token or Card objects. The idea then would be to keep track of all the card fingerprints you see in your database to detect a returning customer. Whenever a customer adds a new card you'd first look if you've seen that card fingerprint before in your database and decide to create the customer or return an error based on this.
Separately, you should not offer Checkout for a customer that already has a saved card. Instead you should show them the card(s) available for example by showing the card brand and last 4 digits. And then the customer can either pay with one of those cards or add a new one.
You can add more than one card to a customer or replace the default one. You can also decide which card to charge by passing both the customer id in customer and the card id in source. This is all covered in details in Stripe's documentation here.
For approximately how long is a Stripe card token (aquired through Stripe.js) valid? According to the docs:
The token is single-use only and has a short life. Use it in an API
call immediately.
I understand I shouldn't store the token for use later, but how short is "short" in this case? Should I expect it to expire within seconds or minutes?
(Although not relevant to the question itself, the reason I'm asking is that I would like to take the token exchange step out of the transaction that the user is waiting for, and let a background job handle the actual Stripe integration. Obviously, that's not a good idea if the token has a very short lifetime.)
The card token is valid for a few minutes (usually up to 10). What Stripe recommends in that case is to use the token now to create a customer via the API first to save its card and then let your background job handle the charge part after the fact.
This also ensures that the card is valid as Stripe runs a $0/$1 authorization on the card first. You can then give feedback to the customer immediately in case of an error.
in our application we allow users to link card to their profile and use it later for payments inside our system. Recently we had a couple fraud attempts when users added stolen credit cards (so they knew all information about card, including CVV).
The only thing that we came up with is to make temporary payment of some small random amount so user can check bank transactions report and verify ownership by providing exact authorized amount.
Is there any other common proven ways to verify card ownership?
Yes, there are a couple of things you can do at the very least:
Validating the house number and postcode/zipcode provided to you with the result returned to your from your payment processor on the pre-auth (AVS - Address Verification Service).
3D secure verification (Mastercard SecureCode or Verified by Visa) - the user is redirected to their issuer's site (or one ran for them by e.g. Arcot) and has to enter a secret only known to them.
Validating a small random amount is also a good check to make, however this takes a few days whereas the above can be validated instantly.
We have a requirement where we need to allow potentially many users to add one message to the Azure Queue Service. Using Shared Access Signatures we can allow users to add messages to the queue for a limited time. But is it also possible to restrict to a maximum of 1 message per SAS token we generate?
Or can a potentially malicious user insert an unlimited number of messages into the queue during the SAS token lifespan?
But is it also possible to restrict to a maximum of 1 message per SAS
token we generate?
Unfortunately not. The token is valid for the time period being issued, and the only limitation of messages sent is the Storage Queue limits.
Or can a potentially malicious user insert an unlimited number of
messages into the queue during the SAS token lifespan?
Yes. This is a valid scenario.
As of today, if you want to have this granular control for a Queue (who sends what/when/how many), you have to gate the traffic yourself.
UPDATE
For Table it is different - you can restrict the SAS token to particular PartitionKey and particular RowKey, thus effectively making the SAS only capable of working with exactly one table row!
Check out the docs. There are parameters spk (start Part.Key), srk (Start RowKey), epk (End Part.Key), erk (End RowKey).
Using Table and Table SAS you can limit the data a single user can send! But the only way to limit the amount of data, or number of requests is by gating it yourself, or make the hard decision about the SAS lifetime.