So I am using Salesforce and Magento for order management in the backend. My customers are placing orders on my marketplace in Magento and then Magento sends the orders to salesforce for reporting. I would like process the orders in salesforce; however, I don't want to be flagged to xss attack or middle man attack by Authorize.net. I want to know if I can use the transaction token and ID that I received for authorizing amount on the customer's card in Magento to capture the funds in Salesforce?
Magento makes api call to authorize.net to auth amount on customer's credit card.
Then Salesforce uses that same authorization token in capture funds.
Yes, you can. As long as you have the proper login ID, transaction ID, and CIM profiled IDs the payment can originate from any system you control.
Related
A customer subscribes to my SaaS product on AWS Marketplace and is redirected to my registration form
My registration form receives the registration token and exchanges it for the product code and customer identification via the ResolveCustomer method of the AWS Marketplace Metering Service
If I understood the AWS documentation correctly this means that now the subscription is active from the perspective of AWS Marketplace, right?
Does this also mean that if I fetch entitlements with the AWS Marketplace Entitlement Service for that same customer they will already be returned without an intermediate step?
The intermediate step being some kind of additional verification or confirmation procedure/API call.
The subscription starts already at the redirect (order confirmation).
Yes, entitlements are available right away, after the subscription starts.
There is no intermediate step.
Everyone can create ethereum token by solidity codes but don't know how can this token integrate as payment gateway in ecommerce website.
For real project . This token need frontend web wallet /android wallet and integration to every website as payment.
Plz suggest me .how can find this way.
What need more to study.
Token is not a payment gateway. If i understand your question correctly, you are asking, how can you interact with a token that you have created through Solidity from frontend. One use case would be how people can use the token that you have created to purchase some item. For this the users should already be holding the tokens. This can be bought from an ICO or from an exchange. Basically there's a couple of functions in ERC20 token i.e., approve() and transfer() that will approve apps like exchanges to perform transactions on behalf of the owner of the token. Once the users have those tokens they can purchase items from it. Again, you have to write the logic how and what you expect users to do.
ERC20 Token is works likes Currency.And solidity is a programming language. which we used for write the smart contract. if you want to invoke your function then you need to create wallet account ,after that you can do transaction using with web3js. you can get ether for testing purpose from faucet.Basically these are functions in ERC20 token i.e., approve() and transfer() that will perform transactions
I don't suggest using ERC20 tokens as payment method.
Ethereum network is not fast enough,you need 30 confirmations to make sure you received the token, some times the delay can be 1 day
Cost is high, when you transfer token ,usually you have a smart contract, it costs lots of gas
Ether price is not stable, it drops 90% of value from Jan 2018 to Dec 2018. it will be hard for estore to maintain profit.
However if you still want to do that, yes, you can create your own gateway using tokens as your accepted currency.
I am making a website where people will buy things. What I am wondering is if there is a way to check if payment was received in paypal, and then execute some code. Or should I add a paypal widget where when payment is done then it executes some code? This is all being done in HTML and CSS being it is a website.
Take a look at Instant Payment Notification (IPN). Any time a transaction hits your PayPal account their server will POST the transaction data to a URL you specify. Your script receives the data, verifies it with PayPal to ensure it actually came from them, and then you can process that data however you need to.
This gives you the ability to update your own database, send out your own email notifications, hit 3rd party web services, or anything else you want to automate when transactions hit your account. This works for payments, refunds, disputes, etc. so you can automate lots of tasks. It happens in real-time, too.
Our platform is trying to create a feature so that a seller can refund a paypal transaction after 60 days. To do this our thought was that we would use the adaptive payment feature and simply ask paypal to send money from seller to buyer.
We created an application, and in the sandbox we have everything working. When we move to production we get this response below.
{"errorId":"550001","domain":"PLATFORM","subdomain":"Application","severity":"Error","category":"Application","message":"User is not allowed to perform this action"}]}
The question is, "How does the seller authorize our platform?" Do they need to check a box in their Paypal account?
What's a bit confusing to us, is that we are testing with our own 'seller' account which is of course a valid Paypal account.
Furthermore, we are doing a simple implicit approval. We did notice that in our application registration we are 'conditionally excepted'. We read that simple payments should work fine, it is only the chained payments that require specific approval from paypal.
can we rely solely on subscr_eot to activate/deactivate an account?
Assume we have the following scenario:
On 9/16, a customer pays using Paypal for a monthly recurring
service.
With 24 hours, Paypal sends "subscr_signup" and
followed by "subscr_payment". At this time, the application will
grant the user access.
??
The question, will Paypal send an EOT before attempting to collect the payment on 10/16 or would it send it before?
Thanks,
subscr_eot means that the subscription has expired, either because the subscriber cancelled it or it has a fixed term (implying a fixed number of payments) and it has now expired with no further payments being due. It is sent at the end of the term, instead of any payment that would otherwise have been due on that date.