We are creating a custom payment service that uses Coinbase as a Bitcoin backbone. I managed to set up Bitcoin address creation (wallets) and the checkout process is actually finished (Bitcoin address is being created).
However, I did not find a way to attach a custom callback URL to an address I've created. The address should "listen" to incoming transactions and trigger the webhook URL.
We cannot use any of the predigested merchant solutions from Coinbase (button / page / iframe) because the payment flow should be deeply integrated into our existing processes, look and feel. Instead the system is just creating a new Bitcoin address and should be notified on incoming transaction events, but without using a merchant solution.
When creating an address using the Coinbase API v2, you get an object that includes the callback_url property. However, it is empty and in the documentation there is no hint on how to specify that.
I thought about polling the addresses, but that could easily exceed the 10,000 requests per hour rate limit. Any clues how to specify the callback_url on address creation (https://api.coinbase.com/v2/accounts/:account_id/addresses)?
I’d recommend a third-party for this - I’ve personally used https://blockchainwebhooks.com and https://www.blockcypher.com - both have been reliable and offer free plans. Blockchain WebHooks is significantly more affordable, that’s what we still used today.
Related
Hey I would love to learn an know how payment gateways are implemented I have been google searching for code examples to implementing PayPal to a MERN Ecom project but I really could not find any examples on this
Can you please refer me to link where I check that up and if possible please you can make just a basic snippet on how this can be implemented I would really appreciate it
This is the kind of implementation I would love to have
Take in the customers Personal info i.e Name, Email and all necessary info etc
I would love to collect a shipping address
I am not sure what about approaches to implementing a server and client side confuses, but below is some documentation to review. The samples are in standard node.js and JavaScript, so no express or react details are considered. Make your own adjustments to use with express and react.
On the server, two new routes, one for "Set Up Transaction" and one for "Capture Transaction", documented here: https://developer.paypal.com/docs/checkout/reference/server-integration/
A client-side approval flow to connect to the above, documented here: https://developer.paypal.com/demo/checkout/#/pattern/server
By default PayPal collects and returns a shipping address, so it will be available to you inside onApprove on the client side, or via an additional API call you could implement to get the details before going ahead with a capture, or simply in the final response of your order capture API call
When you capture an order, there will be a payment object with an ID. That is the PayPal transaction, and what you should persist in a database, and also what would be referenced for any refund. (The order ID used during approval and any debug_id of the response can be kept around for logging purposes, but have no accounting or reporting value)
Do we have webhook available for SAP successfactor?
Do we have any webhook available where I can get the notification if any operation happened in the entity like any object is inserted in the entity then I will get notification?
Yes, it is an inplace functionality called Intelligent Services (can be found in Successfactors within transaction "Intelligent Service Center (ISC)".
There you can subscribe to different events (only the one's provided in the standard, no custom hooks possible). The subscription results in an integration center flow, where data can be passed via different protocolls to a webservice of your choice.
You can also configure a "business rule" with an intelligent service as a starting point.
I am looking to implement an EMV chip reader/payment processor solution with REST API capabilities and Card Verification Modes (CVMs): Chip-and-Signature for Credit Cards and Chip-and-PIN for Debit Cards.
Here is the process flow that I need:
Web Based POS sends transaction to the server.
Transaction information is saved (order number, product numbers, total, etc.). The server sends an API request to the EMV to start credit / debit card payment process. HTTP local network connection.
EMV receives API Request from the server via HTTP and start capturing payment process.
Connects to the payment gateway to process payment. NOTE: EMV must have REST API capabilities.
The payment gateway processes the payment and sends the answer back to the EMV, which sends the answer back to the server to update the transaction record.
The server sends the answer to the host to finalize the transaction, depending on the answer received.
Has anyone implemented this type of solution before? If so, which solution (Square, Clover, etc.) was used?
Your question doesn't really belong to stackoverflow - it's not programming, you have not shown any code nor described what you are doing and what have you done so far.
What you describe is pretty generic description of the Retail ECR protocol. There are numerous variants and implementations, some may expose REST. Some may work with central server exposing REST API to POS, others will have a listening port on the EFT terminal side (there should normally be some firewall limitations on how many connections and what is the connection source, etc.). Almost any acquirer or PSP will have some implementation (however not necessarily with REST over HTTP), so you might want to start with your local service providers as they will probably best reflect your needs where it comes to acceptance methods, card schemes supported, etc.
You could have added a simple illustration to make the interactions clearer. EMV is a specification or a standard FYI.
In Step 2. Did you mean you have an EMV certified terminal which exposes an API, which the server can call to initiate a transaction with card ? In that case HTTP connection is between the server and terminal, and the chip and terminal connection is direct. Correct ? This is do able.
Step 3. Now that the terminal has already communicated with card in APDUs and has at hand a cryptogram( ARQC, which require you to send the request to issuer for verification - Onilne ), you need to communicate with the acquirer. This communication is up to your implementation. You may do it via SOAP or REST or whatever.
Step 4. If an ARPC exists, this should be forwarded to card, which the card will validate and ensure the response is from right issuer. Otherwise it may send the acquirer a reversal( if the response was approved ). If ARPC is validated call host to update on the payment.
In any case if you are looking for a solution where the server will communicate with the card directly it most likely will not work as it will not be able to meet the acceptable timelines between the APDUs.
You have not told your problem yet. Are you trying to ascertain the feasibility of your proposed architecture ?
When I do a Paypal API signature request under business profile, the generated api is using my old website ---whateverAPI.my-old-website.com
I've updated all of my business information and see no instances of the old url in my paypal account or the developer or sandbox accounts.
I do not have the old login information for developer area where I created the original API information as it was changed to my new login/business.
I need to change the URL associated with my account so the api generated has the apicode.new-website.com
I know this is a low level expertise for most of you compared to what you are coding but I am completely stuck and have tried everything I can think of.
Thanks for taking the time to read!
When the API is first requested on an account, it is generated based on the email address associated with the account at the time. Even if you remove the email address and request new API credentials, it will still use that original email address. There is no need for concern, you only set this in your API call or in your shopping cart to use. Buyers are not going to see it or anything, and it's not something you would regularly share or have to use all that often. Once you set it in your code, you don't really mess with it again unless you need to set up the API credentials again.
In Mandrill, if you create a new API key and do not limit its API calls, whoever you give that key to can use it to log into the web interface with full access - billing information, account information, the works.
After playing around, it looks like you can disable the web interface login functionality by ticking "Only Allow This Key To Use Certain API Calls" and then selecting at least one API call. Doesn't matter which one.
So I can give full access to the account, or completely disable their ability to log in. Is there any way to customize this further? I would like to be able to limit users to the outbound/inbound UI, or at least prevent them from having the ability to charge many thousands of dollars to the attached credit card. For clarification, my use case is to distribute API keys to contractors or vendors so that all email gets sent through a single account.
I have found very little official Mandrill documentation on this. The only thing that seemed relevant is that if you have a Mailchimp account, you can instead send users there and use the "View Mandrill Reports" functionality. I don't have Mailchimp (nor do I need it), so this seems like an unnecessary hacky workaround.
Different levels of access, other than limiting API calls for API keys isn't currently possible as described in the Mandrill KB here. If someone has access to the web interface, they have access to the account as a whole. This may, of course, change in the future, and would be documented on the blog and in the KB.
I believe you could also restrict access to the web interface by setting up two-factor authentication?