Can any body explain why sms gateways take money on fail delivery?
Yes i understand that sometimes confirm that sms was delivered its hard but even if services says cant deliver it still take money.
Because then they are not loosing money and why to hurry up? I used when when they answered to me after one week. After one week they answered why sms was not delivered.
As part of question would be how to deal with that because now i see only one option to use two different services and track if user try to send sms twice and account is not confirmed then use other service as previous
The way these services work is that they incur cost on every SMS sent, even if not delivered. Do note that in most of the cases, this is not the telecom provider's cost, as that is pretty minimal because of the bulk purchases these services do. It is more of the cost of their entire infrastructure etc. in sending out that SMS.
To put it in perspective, take case of email service providers. They also charge based on number of emails sent, irrespective of whether the emails are actually delivered or not.
And to minimize this cost, you need to try a few services to see which one has the best data bank of numbers that have least non-delivery rate.
Related
My naive understanding behind how currency trading works on Exchanges like Binance and Coinbase is each users are provided with unique address and when the respective currencies trade happens on exchanges like Binance or Coinbase, both the parties accounts get's updated live on blockchain.
To elaborate more, In case of ETH/BTC trading, let's say, Mr Foo wants to trade his ETH with Mr Bar's BTC on Binance exchange. Binance will provide both of them with unique address respectively to their currency. So when the ETH/BTC trade take place, Mr Foo will receive the BTC on his newly generated unique BTC address and Mr Foo's ETH account will be deducted . On the other side, Mr Bar's BTC account will be deducted and Ether account is updated with newly received ether.
I'm really confuse regarding whether these currency trading on exchanges execute live on Blockchain? Recently during Bitcoin and Ethereum network congestion, I did BTC/ETH trading on HITBTC, the process happened instantaneously, but I've to wait for hours during withdrawal process. Also Hitbtc seems to be using same Ethereum account (0x65e2c5175e2e618f48e70343b14c31b280e42d90) to transfer fund during withdraw request for multiple users. It seems that these exchanges are using the same address for serving multiple users.
Could somebody explain how users accounts are updated during currency trading on exchanges like Coinbase and Binance? Does trading immediately happens live on blockchain? Or Exchanges only shows the users with fake trading balances until it's withdrawn? Do the Exchanges use same address to accept deposits from multiple users?
Thank you for your time.
Check out this thread for a brief explanation of Coinbase's order management.
Answer on the reddit thread, supposedly from a coinbase insider.
In addition, my comment above was just based on intuition and my general knowledge of the way brokers work.
Brokers
Brokers tend to match orders first since they are in the business of exchanging, not investing. Meaning they make their most consistent revenue from fees generated by facilitating customer orders, not by investing in the securities or assets that they help to buy/sell.
Sometimes in order to fulfill an order the broker will go long or short a particular asset class, in this case bitcoin or ethereum, etc. If this happens the broker is exposed to fluctuations in the price of that asset against the asset they are trying to grow (cash).
Now, since Coinbase is heavily involved in crypto it might be part of their strategy to hold Bitcoin or Ethereum inventory, but I would doubt it would figure much since that would undermine public trust in their institution as an impartial exchange. No one really likes to hear their broker bet against them, it tends to engender resentment.
Technicals
Coinbase is setup as a software wallet, meaning you have an account, with the private keys stored on their server. So it is possible for them to facilitate some of the trading between bitcoin accounts without ever having to match orders with an account holder outside their system.
Meaning, they can collect/match/fill the orders in batches and then submit those batches to bitcoin miners. This would allow them to quickly "fulfill" your order, and then send you verification once it has been posted to the blockchain.
Further Reading
Although it is not specifically geared towards crypto exchanges there is an excellent book on the subject of how markets actually function.
Market Microstructure in Practice
(Not sure if this is the right place to ask. Please point out other forums if that's not the case).
I'm based in Europe, and I've set up an invoicing system for a client of ours which uses a tokenization system provided by his bank, as part of the bank's secure payment services. (In other words, this is not any of the big american services like Paypal, Braintree, Stripe...).
The problem is that, in order to input a credit card into the system, this
bank needs to charge an initial amount of 0.01 € to it... and when it does that, the credit card owner gets a text message code to approve that charge, without which the card number cannot be introduced. This is not practical for my client, for a variety of reasons. We have asked the bank, and they say that this is all dependant on the card issuing bank, and they can't do anything about it.
My question is...: what do we do to avoid this? From what I remember, other tokenization system I've used also had an initial 0.01 cent charge, and yet I never received any text messages from them (this was a few years ago, admittedly, before 2FA became widespread). How do the big payment processors (Authorize.net, Stripe, etc.) manage to store credit cards without making an initial charge and triggering two-factor authentication in the process?
Thanks.
The reason behind performing an authorisation (not a charge) is to ensure the card is valid before it is stored.
However, the $0.01 authorisation is now considered 'the old way' of doing this. Most card acquirers now allow an authorisation value of $0.00 to be used solely to check the card is valid. This shouldn't trigger any 2FA where it is supported.
Obviously though, this is payment processor dependant on whether they support this 'new' functionality. A small number are still stuck in their ways
The other alternative is just to process the full transaction value. It shouldn't be necessary to submit the card for tokenisation before using it, though admittedly this depends on your business use case.
I have created shopify app and setting up billing Api. In the App, I want to apply trial period of 20 days. I have created the charge during the app installation and send customers to confirmation url so that they can accept or decline the charge.. So I want to know that if customer decline the payment charge, then can he uses the app featurs till trial period?
If a customer declines the subscription, you still get the confirmation URL callback. Examine the charge. The status will say declined. At this point you can kill off their DB token and destroy their session. This will ensure they cannot use your App as they declined the terms.
It is one bad aspect of the whole billing scenario. I have lots of customers that are faced with a question they don't read. So they assume the trial you offer for free is activated by declining the subscription. Silly customers... still cannot operate the Internet :)
We're trying to setup an incentive program in our work place, we want to setup a self service incentive program where each user gets "points" for completing various tasks and then after a certain threshold be able to convert them points into money. But we just want to use email addresses/phone numbers as the method to pay them. Just like the inbuilt Paypal send money feature.
Is this possible to do via one of their APIs? I've looked through their API's and I can only see receiving money, not sending money....
I would have liked to use Square Cash but that is not available in my country (we're not strictly tied to PayPal if there is an alternative service that will accomplish the goal)
If you have a US Business PayPal account you can use MassPay to send payments from your account by specifying the email address.
https://developer.paypal.com/webapps/developer/docs/classic/products/mass-pay/
The other option is to use Adaptive Payments to send Implicit Payments from your account to another user. You can specify email address, and if you want to pay the fees for the transaction you can specify that in the call.
https://developer.paypal.com/webapps/developer/docs/classic/adaptive-payments/gs_AdaptivePayments/
I'm looking to implement an SMS authentication for one of my projects, basically before a user is able to register an account with us, we would like to authenticate the user by sending sms containing a code to his mobile phone, and get him to put in the code in our form before he can proceed.
I've been looking around and found onVerify to be a pretty good way to go
http://www.onverify.com/
But I'd like to know if there're any other alternatives similar to onVerify as it is a bit expensive, so if I could go with cheaper one, that'd be great.
Thanks!
You can do this easily enough if you have access to an SMS provider.
Typically you send an SMS to the user by making an HTTP request, containing the verification code. You'd store this code, and the recipient number, in some persistent database, against which you can compare when they fill in the details on the form.
You don't mention which geographic regions you expect your users to be in, which can be important given the variable delivery quality in some markets.
Have a look at the HTTP API for BulkSMS, message pricing and coverage.
Note that you can register in various regions, if you, for example, want to price in USD.
Disclosure: I work at BulkSMS