Topic: FastCash4Bitcoins Support Thread - page 51. (Read 94604 times)

My local branch manager told me that Bank Of America has never asked for debit/credit card.  For customers without an account ID is all that is needed and you can't use the drive up teller (need to come inside).   Customers without an account can't cash checks which have a third party endorsements (i.e. we can't issue a check to John Doe and then John Doe sign it over to you and you attempt to cash it without having an account).

Our checks are protected by Positive Pay.  All checks we issue are pre-authorized by providing the check number, payee, and amount to Bank Of America.  Any check not matching a pre-authorization is denied.  If you payout check is lost or stolen in the mail there is no risk of it being modified and fraudulently cashed.

So did you find out if a ID and debit or credit card is needed to cash a BOA cashiers check @ BOA?I know a ID is needed,but what about a credit or debit card issued by a bank?

I personally like it the way is, but coupled with my suggestion below, there should be some way to look up the status of the order. This promotes maximum anonymity (which I think is ideal, but RISKY for you, something you'll need to weigh in with your comfort level).

Keep it so the funding address is given at the same time the Order # is given so the customer can't claim he was given one but not the other. If http fails, then the order is never fulfilled and should be pruned after 2 weeks or so. Key: Display the order # in the html BEFORE the payment address so that if http connection is lost midway through, they still cannot risk their funds by being derpy and sending them even though the page had not fully loaded and they'll never get their order #. Details first, payment second.

Maybe make including an e-mail address OPTIONAL, and if they choose to provide that information you could e-mail them the Order # and link. This would provide a combination of nearly all your options and incorporate the benefits of each.

I think this would be good. Having the Order #s the way they are now makes it easy to remember, but much less secure and much more prone to some sort of tinkering. I'd recommend hashing it with a salt... So Order # 10321 = hash(str(10321)+"lolthisistangiblecryptosalt"). This is simple, but it would be ideal to shrink the hash down to nothing more than 16 characters. 10 would be more ideal. Less opens you to the risk of brute forcing again. This makes it manageable for the customer to keep track of.

I need some feedback. I had intended each sales order to be independent of any outside access.  No email (expect in unresolvable problems) and no accounts.  Maximum security.  There is no user side data to hack, spoof, or impersonate.  No social engineering possible and even if an order is compromised the attacker only has read access to the data.    That may not be realistic.  Roughly 2% of sales required their order number either due to seller never being provided it (connectivity issues) or it being lost or written down incorrectly.

What do you think.  Is having no notifications and no method to lookup order ID a bad idea?
(edited for clarification)

I see 5 possible resolutions:
Option A)
Change nothing.  Sellers should be more responsible.  Major problem with this is http isn't a guaranteed service.  Loss of connectivity could result in seller never getting order #.  I would point out there is never any risk to funds.  If user never saw order # then they couldn't have seen the deposit address and the order will just expire unfunded.

Option B)
Assign order # before sales form is submitted.  Will require changing the code somewhat and seems clunky but it would work.  User inability to record order # is still an issue but it rules out the connectivity issues in A.  

Option C)
Email user their order # and a link to status page on order creation.  Less respect for privacy but the email message would be spartan and non descriptive.  "Order # 99999 has been created.  View status here:"

Option D)
Provide  lookup form for Order #.  The issue is in making it deterministic.  If users is validated by the lookup form, order id would be sent to user.

Option E)
Your idea.

On a similar topic:
What do you think about Order # in general? They are obviously sequential which makes brute forcing them easier.  I never consider usernames to be a secure piece of information but a sequence does make attacking weak passwords significantly easier.  Would it be better to have a Order ID which is not sequential and instead is a hash* of the order details (i.e. Order ID: KJYXLQ).  Of course this added security only compounds the issue of user's forgetting their order #s.

* Well a modified hash to guarantee uniqueness.

Some site enhancements planned:

A detailed transaction log for each sale will be added which should provide more clarity on the process.

Example:

Also coming is an expiration timer so you can better manage your funding. QR code of deposit address will be provided to allow easier funding by mobile wallets.

A slightly less fun enhancement is some basic denial of service protection.  A single IP address requested 2,700 sales orders in the span of roughly 18 seconds.    We put in place some limiters to control the rate of sales order generation and block IP addresses which request an excessive amount.  Captcha was considered but honestly there are few things I hate more than captchas so it will be considered only as a last resort.  I really hope it doesn't come to that.

Update:
Dwolla reloaded.
PayPal reloaded.  
Primary account funding (checks, ACH, etc) reloaded.

For those with ACH payments in transit remember 4th of July is a US Bank holiday so 3-5 business days excludes 07/04.  Got to love the traditional banking system.  Even those there is no human interaction required on any day except the first (day 0) and last somehow the employees being off makes the clock stop.   Imagine if the blockchain worked that way.   When the miner is sleeping, the rig can only hash empty blocks.

For those with inbound checks the 4th is also a US Mail Holiday.

While we are confident our arrangement protects both us and our clients PayPal has been known to be dysfunctional (different departments giving conflicting information) and arbitrary in the past.  We intentionally limit the amount of capital exposed to PayPal and provide alternate payout methods.  In the unlikely event that a sales payment is frozen by PayPal we have already been given assurances in writing that it will always be possible for the payee to refund the payment and we will pay them by alternate means. 

Once again these precautions will likely not be needed but we are prepared to handle any adverse event by PayPal.  Unfortunately this manifests itself as low available balance in PayPal payout options as we attempt to anticipate demand and use some "just in time funding".

I think the next sentence should be included:
"I only bring that up to illustrate the absolute need for manual processing."

It wasn't my intend to sell the irreversibly of our payments.  I simply know from first hand experience than even in the case of an obviously accidental double payment (bit for bit exactly the same API call, yeah PayPal has never heard of a nonce), PayPal would not reverse the payment noting that the terms of our merchant agreement only allow reversals in the event that PayPal issues a payment due to a mistake on their part or compromise of their system.  As PayPal makes their payment system intentionally opaque PayPal users should treat all payments the same as there is no reliable method (likely intentional on PayPal part) to prove type of payment which was issued and under what terms.

I will contact our bank manager for clarification because that doesn't sound like their check cashing policy.  Maybe the customer support rep was confused or mistaken.   As far as third party check cashing services.  It isn't possible for us to know where and under what conditions a check would be accepted.  For those concerned about the cashing of a check we do offer Cashier's check as an option.  No customer has yet reported than one of our checks has been declined or rejected for cashing. 

Taken from his reddit post today:

How are you dealing with PayPal? Surely something bad is bound to happen...

Ok walmart doesn't cash them,check cashing spot doesn't cash them.BOA will cash them,but need a credit or debit card from another bank.I d0n't got that.

Send us a PM.

Please email the order number or have some way of retrieving it. I placed an order, waited half an hour and refreshed the page to see if my bitcoins confirmed, and lost the number.

Update:

A very busy Monday.  I am not sure if it was the rising bitcoin prices or just a sudden burst of popularity, but congrats sellers; you did it.  All funding sources exhausted.  You literally ran us out of money!  All funded orders will be settled today, if you placed an order don't worry your order will settle and close.

We are temporarily closed to new sales until a we can refund our accounts.

Dwolla funding exhausted.  That didn't take long. 

Reloading in progress.  ETA 07/03 by 5PM EST.

Update:
Dwolla funding reloaded.
Primary account (ACH, checks, etc) funding increased.

ok tommorrow, I'll call the local B of A  and check cashing spot,to ask them.

This is all fair and justified IMO, thank you very much for your service!

It is a normal printed business check.  No seller has reported any issue with cashing although I don't know where they are cashing/depositing them.  Our checks can be cashed at any Bank Of America branch without fee (even if you don't have a Bank of America account).  If you are overly concerned we offer a cashier's check as one of our payout options.  A cashier's check is "paid" at the time it is printed.  The check is from Bank Of America's not us, and draws from their account. Cashier's checks are (barring a bank failure) as good as cash.