It doesn't sound like you're approaching this from the best angle. Etherscan is just a web service that monitors the entire network -- relying on it for something like transaction processing is far from the most ideal way to interact with the blockchain.
Ethereum is a distributed network, which means that anyone can run a node that sees the data that Etherscan gets. In practice, this means that you need to run either Geth or Parity (or some other node) to see the entire chain. What do you get from either geth or parity? The JSON-RPC API.
Most of the time, when people implement payment systems using a blockchain, they generate a unique address and private key for each customer transaction. This gives you an assurance that one customer is paying for only one customer's account, and makes your life a lot simpler. The eth_getbalance JSON-RPC endpoint can tell you that an address has a balance. If you've generated a unique address for each customer, you can just query your local JSON-RPC API repeatedly for the balance of the address you issued them. When the balance at that address matches your set price, you know the transaction has been completed. Most companies wait for a given number of "confirmations," aka, new blocks on the network after the transaction containing yours is there. This ensures that no replay attack has been done against you.
This is the most naive approach, but it shows you the technology you need to move forward. In short:
- Run your own node.
- Query your own node for the transaction against a unique address for a customer, using the JSON-RPC API.
- Verify that the address has the amount you expect it to (your transaction has been completed at this point) after a given number of new blocks.
You can improve this by listening for new blocks, watching other events, etc. The JSON-RPC interface is also crude, but some APIs exist on top of it that let you query it easier. For example, check out web3.js.