<p>I was the OP of that last question that you referenced. </p>

<p>Tracking the 'receives' is actually very easy. There are plenty of free APIs (e.g.  BlockExplorer, BitPay/Insight) that'll let you check the status of your inbound BTC transactions with a single API call. It's really a no-brainer.</p>

<p>Sends, on the other hand, are harder to deal with. As opposed to a receive, whose status can be polled with a couple lines of code, a send requires signing using private keys and for obvious reasons, you don't want to broadcast your private keys through a public API. This is what led me down the path of building my own transactions programmatically.</p>

<p>Since the time I wrote that code, quite a few APIs have been made available. BlockCypher, for example, can assist you in building a binary transaction without requiring you to expose your private keys. Building binary transactions isn't exactly straight-forward though, even with an API. Could a person use one of these APIs to build a transaction without having some knowledge of crypto and the native transaction format? Yeah, perhaps, but still not a particularly pleasant process.</p>

<p>Remember, if all you're trying to do is accept Bitcoins for an online store or as payment for services rendered, there's absolutely no need to mess around with any of that low-level stuff that I referenced in my question. Just use a third party service like BitPay. They'll handle all the grunt work including invoicing, transaction building for customer refunds, etc. When I pay for my servers, domains, certs, etc. with BTC I don't think I've <em>ever</em> seen a vendor roll their own Bitcoin billing interface. It always goes through BitPay or a similar service.</p>

<p>My needs and business model are so unusual and specific that a standard package like Bitpay wouldn't work for me. For most use cases though, standard merchant services are the way to go.</p>

CC BY-SA 3.0
2017-12-05T13:28:23.550Z
hi Festus, "Sends, on the other hand, are harder to deal with." - right, that's exactly what I'm wondering.  It seems surprising to me that there is not (yet?) a common service which enables site that have to both receive **and spend** BTC.  (As my BitBall example business would.) But maybe I just drastically misunderstand something. :O
Fattie
CC BY-SA 3.0
2017-12-05T17:48:21.220Z
@Festus I still don't understand why you say sending is harder. You could use almost any Bitcoin wallet software out there, and it would support any address type.
Pieter Wuille
CC BY-SA 3.0
2017-12-05T19:30:59.630Z
@PieterWuille I meant sends are harder to pull off programmatically in code (versus polling for receives) due to the signing component, dealing with the binary format, endianess, etc. From the perspective of a wallet user, these types of operations are point-and-click simple. That's why, if at all possible, I recommend to just use a wallet or for a commerce website, BitPay. It's only a tiny fraction of users like me that will have to worry about hand-crafting transactions in code. Most users can thankfully avoid it like the plague  :)
Festus Martingale
CC BY-SA 3.0
2017-12-05T19:31:53.433Z
But why would you implement any of the signing logic or parsing binary transaction formats yourself? Wallet software will do all of that for you. And I don't mean BitPay (which is a centralized service). I mean software like Bitcoin Core, Electrum, Armory, ...
Pieter Wuille
CC BY-SA 3.0
2017-12-05T19:33:27.277Z
Maybe that's the case now, but at the time (quite a few years back) there wasn't an easy way to hook into Electrum, for example, via an API accessible via .NET, let's say. If that's the new state of affairs, that's awesome! I'll check out your wallet link.
Festus Martingale
CC BY-SA 3.0
2017-12-05T19:36:03.583Z
Bitcoin Core has had an RPC interface that supports sending and receiving since somewhere in 2010.
Pieter Wuille
CC BY-SA 3.0
2017-12-05T19:38:40.183Z
Cool. I guess I was given bad advice then. I was told no way to access from .NET and was pointed to all of these open source projects that I had to compile, etc. to get anything done. I honestly haven't thought about the mechanics of Bitcoin transactions for many years until a few days back when I ran into that problem that you helped me understand.
Festus Martingale
CC BY-SA 3.0
2017-12-05T19:42:49.373Z
Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/69768/discussion-between-festus-martingale-and-pieter-wuille).
Festus Martingale
CC BY-SA 4.0
2021-07-20T21:45:14.433Z
Brilliant discussion. Any tutorial you followed or wrote @FestusMartingale To learn and build (for fun) perhaps?
anotherDev
CC BY-SA 3.0
2017-12-04T23:39:22.223Z
2017-12-04T23:46:09.290Z
2017-12-04T23:46:09.290Z
Festus Martingale
<p>I read this extremely informative QA:</p>
<p><a href="https://bitcoin.stackexchange.com/questions/63934/my-raw-transaction-destroyed-0-0284377-btc-what-did-i-do-wrong">My raw transaction destroyed 0.0284377 BTC. What did I do wrong?</a></p>
<p>For those of us new to the BTC universe, there can be confusion between BTC, exchanges, wallet service providers, BTC-related SAAS providers, and so on.</p>
<p>My question:</p>
<ol>
<li>Notice that the OP in the question has some sort of business which both <strong>takes in and sends out</strong> BTC.</li>
</ol>
<p>I mean to say, those operations are done automatically, by the www-based business in question.</p>
<ol start="2">
<li>Thus the business in question, has &quot;<strong>some sort of software</strong> on a server&quot;, which, can <strong>both receive, and indeed send</strong>, BTC. So far so good.</li>
</ol>
<p>What I am confused about:</p>
<p>it would seem to me that for such a common need, nobody would bother writing their own software to provide those two needs, because I assume, there are any number of large well-known services now which provide <strong>exactly that service</strong>?</p>
<p>(Obviously you might do it experimentally, or as the OP mentioned in the interesting question, it was done some years ago in the early days; or of course the largest enterprises might do it &quot;from scratch&quot;. But surely normally there's just a service which does this via simple APIs?)</p>
<p>Thus, say I want to start a business called BitBall, which is a consignment warehouse for buying and selling baseball cards.  BitBall users (&quot;type A&quot;) send in their baseball cards.  Other BitBall users (&quot;type B&quot;) buy the baseball cards and they are shipped from the warehouse.</p>
<p>Obviously, &quot;type B&quot; users must spend BTC to BitBall, and &quot;type A&quot; users will have BTC paid to them from BitBall.</p>
<p>My question, it seems incredible <strong>that the BitBall programming team would have to program, from scratch</strong>, the BTC related software to enable type A receiving and type B spending ??</p>
<h1>To repeat, my question is about an online operation which has to both <em>send</em> as well as receive BTC programmatically.</h1>
<p>At first I just assumed the major services I had heard about (eg &quot;coinbase&quot;) did this sort of thing but I was wrong. (I think!)</p>
<p>Again in short, surely there are (a number of? well-know?) let us say &quot;merchant services companies&quot; for the BTC universe, which handle both <strong>spending</strong> and <strong>receiving</strong> BTC?  For businesses (example - &quot;BitBall&quot;) which both spend and receive?</p>
<p>Or really, do you just have to plain program it yourself from scratch?  Is there no such thing (yet?) as an in-and-out merchant services API service for BTC handling??</p>

CC BY-SA 3.0
2017-12-04T18:41:05.893Z
Any Bitcoin client can receive and send BTC just fine. Of course everyone will need to do work to integrate it into their own infrastructure (like website integration). The question refers to is about someone who (I think, inadvisably) wrote the sending code themselves.
Pieter Wuille
CC BY-SA 3.0
2017-12-05T13:31:54.430Z
hi @PieterWuille.  Thanks - I don't actually know what you mean by: "Any Bitcoin client."  What is that specifically??  Thanks!
Fattie
CC BY-SA 3.0
2017-12-05T17:25:58.967Z
There are dozens of pieces of software that interact with the Bitcoin network and can receive and send funds. See here for example: https://bitcoin.org/en/choose-your-wallet
Pieter Wuille
CC BY-SA 3.0
2017-12-05T21:53:20.443Z
hi @PieterWuille !  I fully appreciate what you're saying: when you're a "newbie" (no matter my familiarity with traditional payment processing), the BTC "ecosphere" is ..... really confusing!    Note that your answer is "well that's obvious - there are many ...."   :)  I will investigate that helpful link, thanks, and surely be back with more QA on this great SO site.
Fattie
CC BY-SA 3.0
2017-12-05T23:40:33.173Z
I'm just baffled by the situation the referenced question asker was in: somehow deciding that learning the full protocol details and implementing transaction signing logic himself, and in that process never encountering any existing software that could do ot for him. Certainly not all information is trivial to find, but this person clearly spent a lot of time researching things or he wouldn't have been able to implement signing.
Pieter Wuille
<services><merchant-services>
Are there actually merchant services for "outgoing" processing?
Fattie
# Are there actually merchant services for "outgoing" processing?

(Asked by: username_0 on 2017-12-04)

I read this extremely informative QA:

[My raw transaction destroyed 0.0284377 BTC. What did I do wrong?](https://bitcoin.stackexchange.com/questions/63934/my-raw-transaction-destroyed-0-0284377-btc-what-did-i-do-wrong)

For those of us new to the BTC universe, there can be confusion between BTC, exchanges, wallet service providers, BTC-related SAAS providers, and so on.

My question:

1. Notice that the OP in the question has some sort of business which both **takes in and sends out** BTC.

I mean to say, those operations are done automatically, by the www-based business in question.

2. Thus the business in question, has "**some sort of software** on a server", which, can **both receive, and indeed send**, BTC. So far so good.

What I am confused about:

it would seem to me that for such a common need, nobody would bother writing their own software to provide those two needs, because I assume, there are any number of large well-known services now which provide **exactly that service**?

(Obviously you might do it experimentally, or as the OP mentioned in the interesting question, it was done some years ago in the early days; or of course the largest enterprises might do it "from scratch". But surely normally there's just a service which does this via simple APIs?)

Thus, say I want to start a business called BitBall, which is a consignment warehouse for buying and selling baseball cards. BitBall users ("type A") send in their baseball cards. Other BitBall users ("type B") buy the baseball cards and they are shipped from the warehouse.

Obviously, "type B" users must spend BTC to BitBall, and "type A" users will have BTC paid to them from BitBall.

My question, it seems incredible **that the BitBall programming team would have to program, from scratch**, the BTC related software to enable type A receiving and type B spending ??

# To repeat, my question is about an online operation which has to both *send* as well as receive BTC programmatically.

At first I just assumed the major services I had heard about (eg "coinbase") did this sort of thing but I was wrong. (I think!)

Again in short, surely there are (a number of? well-know?) let us say "merchant services companies" for the BTC universe, which handle both **spending** and **receiving** BTC? For businesses (example - "BitBall") which both spend and receive?

Or really, do you just have to plain program it yourself from scratch? Is there no such thing (yet?) as an in-and-out merchant services API service for BTC handling??

**Tags:** services, merchant-services

> **Comments:**
> **username_1**: Any Bitcoin client can receive and send BTC just fine. Of course everyone will need to do work to integrate it into their own infrastructure (like website integration). The question refers to is about someone who (I think, inadvisably) wrote the sending code themselves.  
> **username_0**: hi @username_1.  Thanks - I don't actually know what you mean by: "Any Bitcoin client."  What is that specifically??  Thanks!  
> **username_1**: There are dozens of pieces of software that interact with the Bitcoin network and can receive and send funds. See here for example: https://bitcoin.org/en/choose-your-wallet  
> **username_0**: hi @username_1 !  I fully appreciate what you're saying: when you're a "newbie" (no matter my familiarity with traditional payment processing), the BTC "ecosphere" is ..... really confusing!    Note that your answer is "well that's obvious - there are many ...."   :)  I will investigate that helpful link, thanks, and surely be back with more QA on this great SO site.  
> **username_1**: I'm just baffled by the situation the referenced question asker was in: somehow deciding that learning the full protocol details and implementing transaction signing logic himself, and in that process never encountering any existing software that could do ot for him. Certainly not all information is trivial to find, but this person clearly spent a lot of time researching things or he wouldn't have been able to implement signing.  

---

## 1 answers

### Answer by username_2 on 2017-12-04. Score: 3

I was the OP of that last question that you referenced.

Tracking the 'receives' is actually very easy. There are plenty of free APIs (e.g. BlockExplorer, BitPay/Insight) that'll let you check the status of your inbound BTC transactions with a single API call. It's really a no-brainer.

Sends, on the other hand, are harder to deal with. As opposed to a receive, whose status can be polled with a couple lines of code, a send requires signing using private keys and for obvious reasons, you don't want to broadcast your private keys through a public API. This is what led me down the path of building my own transactions programmatically.

Since the time I wrote that code, quite a few APIs have been made available. BlockCypher, for example, can assist you in building a binary transaction without requiring you to expose your private keys. Building binary transactions isn't exactly straight-forward though, even with an API. Could a person use one of these APIs to build a transaction without having some knowledge of crypto and the native transaction format? Yeah, perhaps, but still not a particularly pleasant process.

Remember, if all you're trying to do is accept Bitcoins for an online store or as payment for services rendered, there's absolutely no need to mess around with any of that low-level stuff that I referenced in my question. Just use a third party service like BitPay. They'll handle all the grunt work including invoicing, transaction building for customer refunds, etc. When I pay for my servers, domains, certs, etc. with BTC I don't think I've *ever* seen a vendor roll their own Bitcoin billing interface. It always goes through BitPay or a similar service.

My needs and business model are so unusual and specific that a standard package like Bitpay wouldn't work for me. For most use cases though, standard merchant services are the way to go.

> **Comments:**
> **username_0**: hi username_2, "Sends, on the other hand, are harder to deal with." - right, that's exactly what I'm wondering.  It seems surprising to me that there is not (yet?) a common service which enables site that have to both receive **and spend** BTC.  (As my BitBall example business would.) But maybe I just drastically misunderstand something. :O  
> **username_1**: @username_2 I still don't understand why you say sending is harder. You could use almost any Bitcoin wallet software out there, and it would support any address type.  
> **username_2**: @username_1 I meant sends are harder to pull off programmatically in code (versus polling for receives) due to the signing component, dealing with the binary format, endianess, etc. From the perspective of a wallet user, these types of operations are point-and-click simple. That's why, if at all possible, I recommend to just use a wallet or for a commerce website, BitPay. It's only a tiny fraction of users like me that will have to worry about hand-crafting transactions in code. Most users can thankfully avoid it like the plague  :)  
> **username_1**: But why would you implement any of the signing logic or parsing binary transaction formats yourself? Wallet software will do all of that for you. And I don't mean BitPay (which is a centralized service). I mean software like Bitcoin Core, Electrum, Armory, ...  
> **username_2**: Maybe that's the case now, but at the time (quite a few years back) there wasn't an easy way to hook into Electrum, for example, via an API accessible via .NET, let's say. If that's the new state of affairs, that's awesome! I'll check out your wallet link.  
> **username_1**: Bitcoin Core has had an RPC interface that supports sending and receiving since somewhere in 2010.  
> **username_2**: Cool. I guess I was given bad advice then. I was told no way to access from .NET and was pointed to all of these open source projects that I had to compile, etc. to get anything done. I honestly haven't thought about the mechanics of Bitcoin transactions for many years until a few days back when I ran into that problem that you helped me understand.  
> **username_2**: Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/69768/discussion-between-username_2-username_2-and-username_1-username_1).  
> **username_3**: Brilliant discussion. Any tutorial you followed or wrote @username_2 To learn and build (for fun) perhaps?  

---

