Although I haven't tried it in production this is how I was thinking of handling the gap issue.
1. generate new address
- - check the current gap
2. If current gap is > 19 then
- - call block.io to send a small payment to the newly generated address
3. discard that address
4. return to #1 (gap should now be zero).
You can check the current gap of addresses that haven't received a payment by calling
https://blockchain.info/v2/receive/checkgap?xpub={xpub}&key={apikey}You’ll get a JSON response like: { “gap”: 12 } if it reaches more than 20 you'll get an error.
So when generating a new address, I'd check the current gap for my xpub, and if it is larger than 19, then I will send a small payment myself to the newly generated address so the gap resets to zero, scrap the address, and generate another new address for the user to use.
The issue here is even though you are sending funds to yourself so you don't lose funds, it will still cost you transaction fees every time there's a 20 address gap. I'd use block.io to send the payment since just sending a payment from a single address will still be within their free api service.
Personally I think BIP32 does not work well with accepting payments online strictly because of the look-ahead issue. This happens with all wallets, it's not just a blockchain.info problem. I'd rather just use a fully functional wallet API, bitcoind or even generate key pairs on the fly and temporarily store them on the server for later once a payment is received to sweep the funds off your server.