In case anyone is interested, i have the following Git Repository running to document the algorithm for this.

[url src="https://github.com/EAWF/Bitcoin-Merchants-Toolbox"]Bitcoin Merchants Toolbox[/url]

1) My bad on the reward. I guess I'm just old-fashioned and used to a world where, if someone makes a promise, or an offer like that, they stand by it, and don't go running to mommy or daddy, or a lawyer, or an escrow holder to weasel out of a deal. I wrote it, I stood by it, and no one was able to follow the terms of the offer.

2) Camouflage: Where you tripped was that you didn't read the offer/directions and follow them.
I asked for an algorithm to begin with the exported account-level extended public key, and you began with the master private key/seed of the wallet.
I'm not looking at the big picture of a creating a wallet. I'm focusing in from the perspective of someone who already owns an HD wallet and want's to trade products and services for bitcoin as a business, and have the remittances show up automatically IN their wallet, under a separate account. 
As you probably already know, HD supported wallets have that fun little "multiple account" feature that allows a seller to have a personal account (i.e. Account 0) and once it's funded, they can open a second account (i.e. Account 1) that can be used to keep sales remittances separated from their personal bitcoin, but the wallet can be used to spend from either account, or even transfer from one account to the other if they so wish.
With that wallet, Merchant's CAN easily export the "CoinType, MainNet, Account-Level" extended public key for use on unrelated servers and have the funds arrive in the HD Wallet's account directly.
I'm building a small toolbox of algorithms (Bitcoin-Merchants-Toolbox) that cover deriving out a "Wallet/CoinType/MainNet/Account/Payment-Address" level public key from the exported xpub, ypub, or zpub, that can be hard-coded into a simple function that will return a payment address to be used on for the customer's bitcoin payment.
Examples:
Merchant's CAN'T do this easily.

3) Libraries: OK, you got me started so ...
<rant>
Let's take bitcoinjs-lib for an example. If you are using it on a web page, then you have two options: <script>embedded js code</script> OR <script src="bitcoinjs-lib.js"></script> in the header. The former method is actually faster because the latter requires another download call to pull in the script from the server.
The smallest version of BitcoinJS-Lib is bitcoinjs-min.js and tops out at 215Kb. If you're only using one or two functions that consist of say 1 or 2Kb of code, then effectively you've wasted time and bandwidth downloading bytes that you didn't really need to get your job accomplished. Not a problem if you get unlimited bandwidth from your server provider, but if the code will be used on a popular site, those bandwidth rates are going to add up to big money which is saved by writing slimmed down(concise) code.
Not to mention that it would take you days of following the spaghetti code to be able to COMPLETELY VERIFY the code as bug-free and thereby trust-able. Hell, I don't even trust the code that *I* write, must less ask YOU to trust what I write.
</rant>

Make sense?

OK, so, the "answers" have convinced me that no one is interested in the reward, so I'm cancelling the reward offer as of this posting. Pooya87 came the closest as (s)he provided the correct formulae, even though it was camouflaged in a lot of other stuff. BUT, since (s)he failed to provide it in the algorithmic form, it's a loser due to a simple failure to read and follow directions.


Thanks to all who participated in this exercise. I'll leave some thoughts and quotes for your consideration and education:

When your customer chooses to put their business online it's a huge risk because they see all the hacks and breaches.  It's a requirement of your program to keep their data safe & secure. For insurance against possible bugs and holes in the code, your code MUST be readable and understandable.

Maybe it will help to think about it this way:
Satoshi didn't just start writing code. The white paper came first. In effect, the white paper is the algorithm for the original bitcoin code.




To the respondents who mentioned or inferred the word, "library" in their answer:

The efficiency and speed of the program is directly proportionate to the amount of lines it has to process within the code. Fill a program with bloated libraries, the program WILL run slower.



Spaghetti code is not "readable" code.

If it were that easy, I wouldn't have asked the question in the first place as I've been banging my head against the Internet for over a year trying to figure this algorithm out.

To help your understanding, the word Algorithm means "a step by step procedure to solve a problem from the beginning to the end," and not, look here and here and here and here and try to figure it out. 

So here's the challenge: Start with the Account Extended Public Key (ypub) and a child index, and describe the complete process required to derive a payment address that equals the payment address listed on Ian's page.

How about I make the challenge interesting and offer $250 USD in BTC at the Bitstamp current market price based on the date that the correct and complete algorithm is submitted here?

However, three rules:
1. The algorithm must be in pure pseudocode (a text based explanation) that an average middle or high-schooler would understand.
2. References to functions such as Base58 encoding/decoding, hexadecimal/binary conversions, RIPEMD-160, SHA-256, SHA-512, as well as string parsing are acceptable.
3. In the case of two or more correct answers arriving, the winner will be the best, most usable algorithm, and the tie-breaker will be the timestamp of the submission.

Here are the test vectors that I will use as proof that the algorithm is correct:

---

1. Access Ian Coleman's BIP36 Mnemonic Generator: https://github.com/iancoleman/bip39 and enter the mnemonic phrase:
2. Select the BIP49 tab.
3. Take note of the Account Extended Public Key section. This will be the first input to the algorithm, the account-level extended public key that would be exported from a Mycelium(Android) wallet, for example.
4. The second input to the algorithm is found in the Derived Addresses section, and for an example, you would probably want to test the algorithm with the first derivation path listed: m/49'/0'/0'/0/0() , so we're looking to derive the payment address listed on that line, the child index of zero.

---

I'm looking forward to the correct answer. I'm told by many that this is a "piece of cake," so it should be easy BTC for someone.

Thanks in advance for your time, consideration and competition.

Does someone have, or can you point me to a definitive resource containing the algorithm for the start to finish ypub to payment address derivation procedure?

Thanks in advance for your prompt response.