<p>I will make my answer a little longer than necesary and mention some things you obviously already know in the hopes that the expanded answer will be useful to others as well:</p>

<hr>

<p>The destination tag should be something that allows the receiving account to perform things like implement "for further credit to..." or to determine which invoice (or other event) a transaction corresponds to without knowing the payer's Ripple address <em>before</em> the payment is made.</p>

<p>As such, it's only meaningful for the <em>receiving</em> wallet. When someone wants to pay using Ripple, you would tell them something along the lines of:</p>

<blockquote>
  <p>Send payment to
  <a href="https://ripple.com/wiki/Accounts#Black_Hole_Addresses" rel="nofollow">rrrrrrrrrrrrrrrrrrrrBZbvji</a>
  and use destination tag <strong>1313426242</strong></p>
</blockquote>

<p>In other words, the destination tag is something that <em>you</em> must create and give to the user, who will then use it when making the payment.</p>

<p>So how to choose a destination tag? Well, there are many ways. Here are a few options:</p>

<ol>
<li>Just give out an incrementing number, so the first transaction gets tag 1, the second tag 2, etc.</li>
<li>Use the invoice number generated by the commerce system you are integrating with. </li>
</ol>

<p>You can read more destination tags and requiring them at the <a href="https://ripple.com/wiki/Require_a_destination_tag_for_inbound_payments" rel="nofollow">Ripple Wiki</a>.</p>

<hr>

<p>Now, your question is what to do about conflicting destination tags. Obviously if you're the only one generating tags for a wallet, then you don't have to worry about that - simply don't generate conflicting tags.</p>

<p>My personal recommendation is to require/mandate that a vendor create a new  Ripple wallet, to be used exclusively by your system. This is certainly not unrealistic. In fact, <em>it's a good idea</em>™.</p>

CC BY-SA 3.0
2014-05-12T20:52:50.843Z
Nik, what you say makes sense.  I only have trouble with the "certainly not unrealistic".  With the new rippletrade, wallet addresses have recognisable names.  It's a shame if I have to switch from ~mycompany to ~mycompany2, just because I switched e-commerce software.  Likewise, if a large team of developers each works on their own copy of a website, they shouldn't each need their own wallet.  To do so is to clutter the ledger.
Dave Cohen
CC BY-SA 3.0
2018-03-12T06:29:52.933Z
@nik Please check this question. https://bitcoin.stackexchange.com/questions/72231/how-to-assign-destination-tags-to-users-for-ripple-address
veeresh kumbar
CC BY-SA 3.0
2014-05-10T06:03:13.640Z
2014-05-10T06:03:13.640Z
Nik Bougalis
<p>I'm assuming you're only trying to accept incoming payments. And I'm assuming that each payment refers to a specific transaction that you already know about. So, basically, you just need to tell others how to pay you. You shouldn't need any Ripple-specific information from them.</p>

<p>Obviously, you'll need to tell them the Ripple account you want them to make the payment to. And you'll find the payment because you'll be watching for payments to your own account.</p>

<p>The only problem is this -- when you get a payment, how do you know who paid you and why? And the answer is this simple -- every time you ask someone to pay you, give them a new destination tag. When you receive a payment, check the destination tag in your database, and then you'll know who paid you and why.</p>

CC BY-SA 3.0
2014-05-11T16:50:45.747Z
I believe the questioner understands all that but is building a system others will use and wants to know how concerned they should be about (and how to avoid) conflicting with those other people's own use of destination tags.
dchapes
CC BY-SA 3.0
2014-05-12T02:15:11.960Z
Yes, I'm building an add-on to Drupal Commerce that makes Ripple an option on checkout.  I'm concerned a vendor might re-use a wallet that has previously been used with another ecommerce system.  Or, a developer tests the configuration on a local server, then later a live transaction appears to be paid because it generates the same destination tag that the developer's earlier test generated.
Dave Cohen
CC BY-SA 3.0
2014-05-12T02:23:08.843Z
One good solution might be to allow them to reserve a range of destination tags, say 50 million of them.
David Schwartz
CC BY-SA 3.0
2014-05-12T14:28:46.203Z
I suppose my module could offset the destination tags by some amount, and avoid collisions between a team of developers working on the same site with the same wallet.  However, the wiki recommends randomizing each destination tag.  So it wouldn't be safe to ever re-use a wallet that has been used with any other commerce system.  (https://ripple.com/wiki/Require_a_destination_tag_for_inbound_payments#Choosing_a_tagging_scheme)
Dave Cohen
CC BY-SA 3.0
2014-05-12T18:46:48.883Z
@DaveCohen You can pick a random destination tag within a range of, say, 50 million tags. The main point of randomization is that a destination tag doesn't reveal when it was created or how many have been created between two such tags.
David Schwartz
CC BY-SA 3.0
2014-05-12T20:41:45.487Z
I get that.  I'm pointing out that my software can't detect any difference between a wallet with a safely reserved set of tags versus a wallet with no safely reserved set of tags.  If, say, you're switching your online store from Magento to Drupal, you *must* use a new ripple account.  Similarly, if you're a developer working on 10 different e-commerce websites, you need 10 wallets (unless each set-up supports a reserved block of tags, and you're careful).  In short, a globally unique tagging scheme is on my wishlist for Ripple.
Dave Cohen
CC BY-SA 3.0
2014-05-12T23:46:03.290Z
You could get away with all schemes using random destination tags, I think. But I agree, there's no perfect solution unless all schemes support a reserved tag range.
David Schwartz
CC BY-SA 3.0
2014-05-11T10:53:34.643Z
2014-05-11T10:53:34.643Z
David Schwartz
<p>I'm integrating Ripple with a commerce system, to accept payments to a Ripple wallet.</p>

<p>My understanding is that the destination_tag, an integer, is the only data I can use to track a transaction.  I can specify the destination_tag when I send the user to their wallet, and it will be tracked in the ledger.</p>

<p>If I'm correct this is the only parameter, I'm worried about conflicting destination tags.</p>

<p>Am I correct that if a wallet is being used with my system, it can't be used with any other, as they might use the same destination tag?</p>

<p>When a user of my system specifies their ripple account (wallet), am I expected to query the ledger for all past transactions to that wallet and, if any, throw an error that the same wallet can't be used with two payment systems?</p>

<p>Do I have to store not only the account id, but also the ledger sequence when my system learned the account id, so that I only search for transaction ids after that ledger sequence?</p>

CC BY-SA 3.0
2014-05-09T21:23:23.093Z
There's also the invoice id field which is larger; it wasn't spec'd for in URI's directed at the "old" javascript client; I don't know if this has been changed for the "new" rippletrade.com client or not.
dchapes
CC BY-SA 3.0
2014-05-09T21:36:24.953Z
I need to limit this to the URIs.  I'll keep an eye out if it changes with the new client.
Dave Cohen
CC BY-SA 3.0
2018-03-12T06:06:05.303Z
@DaveCohen i am also integrating ripple for my web application. Please tell ,e how to assign tags to the users. i am little bit confused about this stuff. please help
veeresh kumbar
CC BY-SA 3.0
2018-03-12T06:29:12.383Z
@DaveCohen Please check this question. https://bitcoin.stackexchange.com/questions/72231/how-to-assign-destination-tags-to-users-for-ripple-address
veeresh kumbar
<ripple><ripple-api>
destination_tag best practices when integrating Ripple
Dave Cohen
# destination_tag best practices when integrating Ripple

(Asked by: username_0 on 2014-05-09)

I'm integrating Ripple with a commerce system, to accept payments to a Ripple wallet.

My understanding is that the destination\_tag, an integer, is the only data I can use to track a transaction. I can specify the destination\_tag when I send the user to their wallet, and it will be tracked in the ledger.

If I'm correct this is the only parameter, I'm worried about conflicting destination tags.

Am I correct that if a wallet is being used with my system, it can't be used with any other, as they might use the same destination tag?

When a user of my system specifies their ripple account (wallet), am I expected to query the ledger for all past transactions to that wallet and, if any, throw an error that the same wallet can't be used with two payment systems?

Do I have to store not only the account id, but also the ledger sequence when my system learned the account id, so that I only search for transaction ids after that ledger sequence?

**Tags:** ripple, ripple-api

> **Comments:**
> **username_1**: There's also the invoice id field which is larger; it wasn't spec'd for in URI's directed at the "old" javascript client; I don't know if this has been changed for the "new" rippletrade.com client or not.  
> **username_0**: I need to limit this to the URIs.  I'll keep an eye out if it changes with the new client.  
> **username_2**: @username_0 i am also integrating ripple for my web application. Please tell ,e how to assign tags to the users. i am little bit confused about this stuff. please help  
> **username_2**: @username_0 Please check this question. https://bitcoin.stackexchange.com/questions/72231/how-to-assign-destination-tags-to-users-for-ripple-address  

---

## 2 answers

### Answer by username_3 on 2014-05-10. Score: 1

I will make my answer a little longer than necesary and mention some things you obviously already know in the hopes that the expanded answer will be useful to others as well:

---

The destination tag should be something that allows the receiving account to perform things like implement "for further credit to..." or to determine which invoice (or other event) a transaction corresponds to without knowing the payer's Ripple address *before* the payment is made.

As such, it's only meaningful for the *receiving* wallet. When someone wants to pay using Ripple, you would tell them something along the lines of:

> Send payment to
> [rrrrrrrrrrrrrrrrrrrrBZbvji](https://ripple.com/wiki/Accounts#Black_Hole_Addresses)
> and use destination tag **1313426242**

In other words, the destination tag is something that *you* must create and give to the user, who will then use it when making the payment.

So how to choose a destination tag? Well, there are many ways. Here are a few options:

1. Just give out an incrementing number, so the first transaction gets tag 1, the second tag 2, etc.
2. Use the invoice number generated by the commerce system you are integrating with.

You can read more destination tags and requiring them at the [Ripple Wiki](https://ripple.com/wiki/Require_a_destination_tag_for_inbound_payments).

---

Now, your question is what to do about conflicting destination tags. Obviously if you're the only one generating tags for a wallet, then you don't have to worry about that - simply don't generate conflicting tags.

My personal recommendation is to require/mandate that a vendor create a new Ripple wallet, to be used exclusively by your system. This is certainly not unrealistic. In fact, *it's a good idea*™.

> **Comments:**
> **username_0**: Nik, what you say makes sense.  I only have trouble with the "certainly not unrealistic".  With the new rippletrade, wallet addresses have recognisable names.  It's a shame if I have to switch from ~mycompany to ~mycompany2, just because I switched e-commerce software.  Likewise, if a large team of developers each works on their own copy of a website, they shouldn't each need their own wallet.  To do so is to clutter the ledger.  
> **username_2**: @nik Please check this question. https://bitcoin.stackexchange.com/questions/72231/how-to-assign-destination-tags-to-users-for-ripple-address  

---

### Answer by username_4 on 2014-05-11. Score: 1

I'm assuming you're only trying to accept incoming payments. And I'm assuming that each payment refers to a specific transaction that you already know about. So, basically, you just need to tell others how to pay you. You shouldn't need any Ripple-specific information from them.

Obviously, you'll need to tell them the Ripple account you want them to make the payment to. And you'll find the payment because you'll be watching for payments to your own account.

The only problem is this -- when you get a payment, how do you know who paid you and why? And the answer is this simple -- every time you ask someone to pay you, give them a new destination tag. When you receive a payment, check the destination tag in your database, and then you'll know who paid you and why.

> **Comments:**
> **username_1**: I believe the questioner understands all that but is building a system others will use and wants to know how concerned they should be about (and how to avoid) conflicting with those other people's own use of destination tags.  
> **username_0**: Yes, I'm building an add-on to Drupal Commerce that makes Ripple an option on checkout.  I'm concerned a vendor might re-use a wallet that has previously been used with another ecommerce system.  Or, a developer tests the configuration on a local server, then later a live transaction appears to be paid because it generates the same destination tag that the developer's earlier test generated.  
> **username_4**: One good solution might be to allow them to reserve a range of destination tags, say 50 million of them.  
> **username_0**: I suppose my module could offset the destination tags by some amount, and avoid collisions between a team of developers working on the same site with the same wallet.  However, the wiki recommends randomizing each destination tag.  So it wouldn't be safe to ever re-use a wallet that has been used with any other commerce system.  (https://ripple.com/wiki/Require_a_destination_tag_for_inbound_payments#Choosing_a_tagging_scheme)  
> **username_4**: @username_0 You can pick a random destination tag within a range of, say, 50 million tags. The main point of randomization is that a destination tag doesn't reveal when it was created or how many have been created between two such tags.  
> **username_0**: I get that.  I'm pointing out that my software can't detect any difference between a wallet with a safely reserved set of tags versus a wallet with no safely reserved set of tags.  If, say, you're switching your online store from Magento to Drupal, you *must* use a new ripple account.  Similarly, if you're a developer working on 10 different e-commerce websites, you need 10 wallets (unless each set-up supports a reserved block of tags, and you're careful).  In short, a globally unique tagging scheme is on my wishlist for Ripple.  
> **username_4**: You could get away with all schemes using random destination tags, I think. But I agree, there's no perfect solution unless all schemes support a reserved tag range.  

---

