I'm brand new to Solidity, and I completed a tutorial to create my own token.
Is there a way to automatically transfer my tokens to specified addresses at some time interval? In other words...
What code should I add to the contract that will transfer 100 tokens to wallet address 0x... once a day forever into the future?
I used the code at the Ethereum Foundation's website: https://www.ethereum.org/greeter
Smart contracts need to be called, they can't start a transaction by themselves.
You can add a function that can be called once a day giving 100 tokens to a wallet.
(Use "now" to get the timestamp and verify it hasn't been called today)
But you will need to make a transaction calling this function each day.
Related
I am using Rails 7 and the Pay gem to create an auction/bidding website. A user places a bid, and through pay gem/stripe I am setting up a PaymentIntent and setting the capture_method as "manual". If the user is outbid then we cancel that PaymentIntent and setup a new one for the new bid. When the user wins the bid then we capture that PaymentIntent. All works well for a use case where bids are flowing in regularly.
But in testing I have come across the situation where the PaymentIntent is automatically canceling after a 7 day expiration period. There could be a situation where the auction goes for a month and so the first few bid(s) sit there for more than 7 days and I would rather them not be canceled.
Is it just a simple solution as setting up a delayed job that runs before 7 days where it cancels and creates a new PaymentIntent? Seems like it's straight forward but I worry about the users credit card statement and seeing authorized charges coming in and out.
Looking through Stripe documentation I know that if using Terminal you can request an extended_authorization, but we aren't using Terminal obviously. But not seeing a way to reauthorize instead of capture a PaymentIntent
Overall you have two options:
Cancel and re-authorize as you stated. Yes this can lead to confusion for the Ccstomer if they see multiple auth's on their statement. It is up to the issuer for when they drop those canceled auth's off the statement.
Use a SetupIntent to collect a payment method ahead of time and then charge it once the bidding is complete. The challenge here is that there is a chance that the payment method is set up successfully but then the issuer decides to decline the actual charge at which point you would need to bring your customer back on-session to collect a new payment method and charge that one.
Implementing subscriptions on an iOS app means we want to handle SSEs in case of subscription status change, as to manage the user's rights inside the service.
The Apple documentation doesn't show an explicit customer GUID.
They provide, in each SSE's payload, receipts, e.g. the latest one.
The question is: how can an API server uniquely identify customers?
Should the API server keep track of every receipt, in an inheritance way?
I.e. should the API persist every receipt, and a link to the previous receipt, up to the first
one that was emitted (which can be linked to a customer through the iOS app the user used to initiate its subscription), and re-trace this history on every SSE?
Per this thread, the applicationUsername service-side UUID (used by apple, for "irregular activity checking") isn't a solution, as it isn't provided in receipts or SSEs. The thread hints that using the transaction IDs is still the best way to identify a SSE, as it is ultimately tied to a user, and it is up to the service to keep track of transactions made by the user on the Apple platform for the given service.
Isn't there an easier, more direct, way, to establish the relationship between a SSE, its apple customer, and the service's user?
After digging for a while and asking around, I reached the following conclusion:
There is only one way to tie a transaction event to a user, and that is by the
restoration mechanism one has to implement on their application.
For this reason, you need to at least keep track of original transaction IDs,
so when the restoration mechanism is triggered on your app, you can check the
currently logged user on your app, and call your back-end with the logged user,
and a list of original transaction IDs.
Usually, when a user subscribes, it is mainly done from within your app, so you
can do this link in a trivial way.
But, because you can "re-subscribe" from the AppStore after a while, without
going through your app, Apple may send a SSE to your back-end which would contain
a new (hence unknown) original transaction ID, since this new subscription is
has a new transaction.
In short,
You need to keep at least a DB of original transaction IDs you receive as SSEs
You need to implement the restoration mechanism as to contact your server every
time the app starts, with the list of transaction IDs / original transaction IDs Apple gives you
You need to accept having transactions stored in your backend without a link
to a user (because the user may have re-subscribed without launching the app yet)
Is it possible to create a feeless ERC20 token?
Or paying fees through another address?
I have a solution in mind, to refund the transaction fee amount to receiver’s adress from a central address.
Any ideas?
You can't have another address pay for transaction fees. You have two options:
Create a centralized server that your app makes calls to which will then delegate all of the activity to your contract. However, this approach is centralizing your app when one of the goals of the blockchain is decentralization. It's up to you to decide if you're ok with this (For example, MetaMask is a popular tool, but that centralizes your provider...is that wrong?).
As you said, you can refund the transaction fee back to the user. Have your contract track individual balances and periodically issue refunds. Your contract can hold funds (which you can replenish through an ownersOnly payable fallback function) and process refunds when appropriate. Be sure to follow appropriate withdrawal patterns.
On the getting started page for Apple Pay, it says that Apple Pay supports "partial shipments." How is this implemented in practice? I know how to get a token from a successful PKPayment. Once I get that token, how do I use it to implement multiple sub-order payments through my payment gateway?
For example, say the user validates a total $100 purchase through Apple Pay of two separate suborder shipments ($40 and $60 each) and I now have an associated token for the $100 order. Because of restrictions on some networks, we can't capture each payment until the associated item has been shipped, and they ship at different times.
Do I have the ability to authorize and capture payments of any amounts using that token?
What is the best approach to authorizing and capturing those sub orders?
Do I auth for the total ($100) and then auth for each sub total ($40, $60) at shipment and then capture for each sub total? If so, then I will be potentially authorizing more than the necessary total ($200), and that doesn't seem right. Is it valid to just skip auth for the total, auth for each sub total, and then capture the sub totals as they ship?
You can't capture an authorization more than once. For stripe you would need to save the token to a customer, and charge the customer for each shipment separately. This isn't only the best way it is the only way to do it.
Once you have a token and attach it to the customer object in stripe, you have the ability to charge it at any time & any amount up until the expiration date or if they remove the card from their apple pay account, like you would any other card regardless of the initial authorization.
The rest of your questions will vary by opinion as there are different ways of doing it, but here is how I would charge this type of order. I think this method benefits both the business and the customer, in addition to keeping stripe/apple happy. This isn't apple pay specific, I would treat most orders with these requirements the same. Also keep in mind apple pay supports it, but it is not required. You can collect all up front regardless of shipment dates.
Generate token from PKPayment for $100
Create customer(if needed) & add token to customer
Create charge against customer using that card for $100 without
capture
Within 7 days assess expected shipping dates.
Once assessment is complete immediately capture only the amount
expected to ship within a week on the initial charge. In your
example this is where I would capture $40 for the first charge. If
nothing is expected to be captured issue a complete refund.
Any shipments beyond the 7 days, create individual charges for the
shipments using the customer object, not the token. Again in your example this is when the $60 shipment goes
out charge that here.
As long as the second shipment charge doesn't happen to go out earlier than the 7 days this would prevent any authorizations overlapping resulting in holds of more than the initial amount at any given moment. I would treat almost any transaction like this apple pay or not.
I want to Integrate Authorized.Net ARB and AIM together using rails.
Actually, I want Instant payment when user signs up today and I want the subscription to start today. for this i want to charge their first payment via the AIM API. and if AIM tranaction get succeed then only i will create ARB.I write code for both my ARB works perfect but when i write code for the AIM it gives error This transaction has been declined but when i create an ARB with same card it works perfectly.I really don't know how to go for this.
Also I want to know when subscription is declined when processing a future scheduled payment is Authorize.Net cancelled that Subscription or try again on next day?if it try next day again how many times it will try? Can I check or write a code using SILENT POST that after 5 times it's subscription should get cancelled.
ARB performs no validation of a credit card when a subscription is created (other then validating the card has a valid card number format, properly formatted expiration date, etc and won't expire before the first payment is scheduled for). Therefore you have to use AIM to validate the card first, either by running a transaction or performing an AUTH_ONLY, and then if it is successful establish the subscription with ARB. Basically once you get that decline from AIM your script should abort and notify the user of the error and have them try again with a new credit card.
If a subscription payment is declined the subscription will be suspended. If you update the subscription before the next scheduled payment is due the missed payment will automatically be attempted again and if successful the subscription will be active again.
There is no way through any current API to check the status of a subscription. It currently can only be done through the control panel. It is on their to do list so this may change in the future.
UPDATE 2011-12-01
The ARB API now offers the ARBGetSubscriptionStatusRequest call to get a subscription's status.