2

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?

  • 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. – dchapes May 9 '14 at 21:23
  • I need to limit this to the URIs. I'll keep an eye out if it changes with the new client. – Dave Cohen May 9 '14 at 21:36
  • @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 Mar 12 '18 at 6:06
  • @DaveCohen Please check this question. bitcoin.stackexchange.com/questions/72231/… – veeresh kumbar Mar 12 '18 at 6:29
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 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.


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™.

  • 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 May 12 '14 at 20:52
  • @nik Please check this question. bitcoin.stackexchange.com/questions/72231/… – veeresh kumbar Mar 12 '18 at 6:29
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.

  • 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 May 11 '14 at 16:50
  • 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 May 12 '14 at 2:15
  • One good solution might be to allow them to reserve a range of destination tags, say 50 million of them. – David Schwartz May 12 '14 at 2:23
  • 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. (ripple.com/wiki/…) – Dave Cohen May 12 '14 at 14:28
  • @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 May 12 '14 at 18:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.