I want to add 'pay with ethereum' feature to my website and i know in ethereum we have a HD wallet which gives us some account, but i don't know for something like payment should i generate new account each time for a new invoice? and then transfer ether into main account?
is smart contract involve in this solution or not.
I'm using dotnet core (c#) , ganache as test-chain and nethereum.
There are three ways to create a payment gateway on Ethereum
HD wallet as you described - not different approach from Bitcoin days
A single forwarded smart contract that separates the customers by their reference number in a Data field of the transaction. Note that the data field is automatically filled by MetaMask and such wallets, so the users will never see this. Note that if people are not using a proper wallet like MetaMask or Trust mobile, but try to make a payment from centralised exchange, this approach would reject their payments.
Example: https://github.com/TokenMarketNet/smart-contracts/blob/master/contracts/PaymentForwarder.sol
A master smart contract that deploys a new payment forwarder smart contract to each customer address making a payment. In this case, addresses are made deterministic by CREATE2 EVM opcode. Coinbase uses this approach as it makes the payment processing non-custodial and Conbase itself cannot steal the money from merchants. Any fees can be baked in the smart contract.
https://blog.coinbase.com/usdc-payment-processing-in-coinbase-commerce-b1af1c82fb0
You don't need new account per invoice, you just need to maintain one account. There are two ways to do this according to me:
You can make your smart contract or use some open source token transfer contract to allow transfer of token from the sender to your account.
You can use some existing crypto currency based payment gateway like b2binpay https://b2binpay.com/
Let me know if this was helpful.
Related
Is that possible to charge paypal customer manually. I can do it like user get redirected to paypal to confirm all the details but i do need that user allow my system to charge him every month without any confirmations from his side.
Currently i'm using the same approach as listed Paypal .Net Sdk example
But it doesn't have such a func to manually charge a user. If someone could chare links it'd be grateful.
Thanks in advance.
without any confirmations from his side.
That would require having a billing agreement on file. There are some reference transactions or "future payments" API solutions that use this, but the feature requires business approval from PayPal.
An alternative that does require confirmation from the buyer would be to send them a PayPal invoice, manually via https://www.paypal.com/invoice/create or programmatically via the Invoices API
Good Evening.
I'm programming a backend containing an HTTP API that allows the client to login or register through a provided phone number. Because of this, this process is quite different from traditional authentication flow.
Because phone number oriented authentication is not secure (but extremely convenient), you can't allow a user to login into someone else account solely using phone number, which was a common case that can happen in phone number recycling cases (example is Lyft).
That's why i thought to emulate just a part of how Lyft currently handle with this, by requiring the user to specify his email during registration and account recovery (i guess login is made with an additional magic string from the smartphone).
In my Web API, for the sign in process, the user sends the following data: phone number, smartphone id, and sms verification id and code.
That's when the business rules for authentication take an important role:
If the smartphone id doesn't correspond with the phone number stored in the database (maybe the phone was changed or reset), the server assumes that the number is already owned by another user and responds with 409 (Conflict)
If the number is not owned by anyone, the server responds with 403 (Forbidden), that means that you're free to register a new account with that number.
The successful path is when the smartphone id corresponds with the phone number, two tokens are returned to the client (refresh and access tokens).
For registering (sign up) there's also a almost similar set of business rules, the registering process also requires the user email for later account confirmation (and invoices), this confirmation effectively associate the phone number and email with that client.
That same email can be later used to recover a account (if the user switched smartphone or number), thus preventing the common problem associated with phone number authentication.
I choose to decouple Identity from my domain model, which is named PhoneNumberAuth (i even created a bounded context).
I have a load of questions concerning this. ASP.NET Identity it's the common way to do authentication in standard ways (email, external, etc).
Should i extend Identity classes to cover my custom business rules? If so, what's the best path?
Should i instead create a façade classe to implement my business rules? Like i did here: https://gist.github.com/Henry-Keys/856bc84355b30c4095c88b8c28d547da
In one or another case, i will end up using Identity for Authorization (roles, claims, etc).
I just want help (or a guideline) to end up with the best solution.
[EDIT]
One thing that i want is to generate email confirmation token, Identity provides a easy way to generate and manage them. But it's difficult to integrate Identity with my custom authentication in order to achieve that.
I'm currently implementing an Automation system for software selling through Paypal API. I have got the IPN portal working so it recieves IPN Messages from Paypal and is passed to a back-end service which files it in a SQL DB, Generates a license yadda yadda yadda. It also checks against an internal entry to confirm the payment recieved matches the actual price of the product purchased (Stopping them sneaky hackers). I have now got to a stumbling block where i would like to reject payments that are the incorrect price and i've trawled the Paypal API Developer documentation and can't seem to find what i'm after. My guess is making a call to the Adaptive or merchant API URLs but I cant find what info past auth credentials i'd need to send. Can anyone point me to the right page or 3rd party website with the information I can use to get this setup? an NVP solution would be preferred.
You can't really reject a payment at that point because the transaction has already been completed. All you can do is refund it, which you can do via the RefundTransaction API within your IPN script. This way you'll also get your PayPal fee refunded.
You've already got your logic in place to check if the prices match, so just add a call to RefundTransaction if the price does not match. You may also want to send an email notification to the buyer in such cases letting them know something was wrong with the pricing on their order so it's been refunded, and maybe even provide a checkout button for them to re-buy at the correct price if you want to.
I'm working on a subscription data delivery webservice using C# and WCF. Customers will sign-up to use the service at different usage levels for a monthly fee. The project requirements call for the service to be accessible from a web app hosted on the same server, from a desktop app and Windows service distributed to customers and from a WordPress plugin. In the future, support may be added for other CMS systems and mobile (Apple/Android) apps.
The security requirements include a standard user ID and password authentication for each call to the service to verify subscription status and type and to track user activity. That's easy enough to do but there's more and that's what I'm looking for advice on.
First of all, there's the need to track IP addresses and use this information to control access. One part of this is to restrict the number of different IP addresses the service can be called from within a specific time period per ID and subscription type. The second part is to prevent access to the service from certain countries entirely. I've read some other answers here about how to implement IP address detection/tracking in general but I am more concerned about potential difficulties associated with this that others have encountered. What should we watch out for here?
The second major security requirement is to restrict access to the service to our provided desktop/service applications or from authorized domains using our CMS plugins. I'm not sure how this can be implemented other than using some sort of authentication token which of course could be easily hacked. Perhaps in combination with the login and IP address requirements this will be enough though. Are there any alternative methods that might be a better approach to take?
Does anyone know a way to facilitate payment between two parties via our website similar to how eBay facilitates payments between sellers and buyers, with buyers using their credit cards to make the purchases? We built a solution around PayPal, but now PayPal is telling us that we cannot use it because that is against the credit card association rules.
Here's what they wrote:
Per our Acceptable Use Policy, under credit card association rules, PayPal
cannot permit the use of the PayPal service as a funding method for payment
processors to collect payments on behalf of merchants.
I would be greatful for any leads. As a start-up, third-party payment aggregation services are very cost-prohibitive.
I think you need to set yourself up as an escrow service between the buyers and sellers. Rentacoder.com does something like this: http://www.rentacoder.com/RentACoder/DotNet/SoftwareBuyers/SoftwareBuyerFAQ.aspx#SafeProjectEscrow
If you are looking to move away from paypal and not be an escrow service yourself, look at escrow.com and its competitors to just use an escrow service.