Security of API Keygen for a cryptocurrency trading platform
It feels like you are combining lots of hashing and string transformation in hopes that complexity will make your scheme more secure.  That's not engineering or computer science, though — it's Cargo Cult Programming.

There are two ways that an API key scheme could work:


To generate the API key, concatenate the username with a salt and site-wide secret, then hash it.  When it is later presented, verify it by concatenating the username, salt, and secret, and see if the hashes match.

Advantages:


It may be possible to verify the API key without a database lookup.
You can immediately revoke all API keys ever issued by simply changing the site-wide secret.


Disadvantages:


It's tricky to revoke the API key for a particular user without a database lookup.

Generate any distinct, unguessable string.  Store it in the database, associated with the user.  When it is later presented, verify it by looking it up in the database.

Advantages:


It's easy to understand how it works.


Disadvantages:


Verification requires a database lookup.



What you have done is a combination of the two strategies.  You store the generated API key in the database, associated with the user.  However, while you could have used just any random string, you used a convoluted process involving lots of randomizing, hashing, concatenating, and shuffling, all without much justification, and in a way that offers no additional security benefits.

Consider, for example:

$hash_merge = array_merge($hashed_b, $hashed_a);
$from_merge = implode($hash_merge);
$exploded_2 = str_split($from_merge);
$key_hash_last = implode($exploded_2);


That just converts an array to a string, back into an array, and reconstitutes the same string again.

If you consider the properties of cryptographic hash functions, you will notice that much of the manipulations are unnecessary.  In particular, cryptographic hash functions are designed such that if inputs a and b differ by as little as one bit, hash(a) and hash(b) will not resemble each other at all.

Therefore, if you choose option (2), you can generate an API key securely using something as simple as

$api_key = hash('sha256', (time() . $id . $some_sitewide_secret . rand()));


The result will be secure because:


Cryptographic hashes are one-way (irreversible) functions, so knowing the hash reveals nothing about the input that was hashed. (Unguessable)
The input varies by time and includes randomness, so it is not repeatable. (Distinct)
The input includes the user ID, so no two users should be able to generate the same key. (Distinct)
The input includes some site-wide secret string (which you can set in your configuration file), so even if an attacker tried to generate a lot of keys using the same technique in an attempt to brute-force a match, knowing the approximate time at which the key was generated and even cracking the pseudorandom number generator would not help.  Pick a very long random string for the site-wide secret (a SHA-256 of any word processing document would do). (Unguessable)
The output has 256 bits of entropy, which is impossible to crack by exhaustive enumeration. (Unguessable)


Furthermore, the chance that the same API key would be generated twice is about 2-250.  It's more likely that your server would be struck by an asteroid tomorrow than that it would generate the same key twice using this technique, so don't worry about accidental collisions.