Do you have any plans to steal Michael O away from Epass to handle your customer service?

I'm sure it wouldn't take much to woo him away from that mess.

:thumbsup:thumbsup

The accounts are FDIC insured.

Woooot!!

This wasn't just talk I see... (not that I had thought so either) ;)

Chio, I may very well be SOOO signed up with Your solutions in a while! :thumbsup

Looks great, I think has potential if it can last. :)

I have lost tens of thousands to processors :Oh crap

I was referring to the people squabbling over the $1.50 transfer charges.

When Paycom and Epassporte split, that should have been massive red flags for everyone.

gr8 stuff............

Allow to respectfully disagree one that, when you are dealing with people's money a simple good track record aint enough.

Plus things can and do go south alot in this area, just ask anybody that has been around for a few years ;)

IMHO there is a serious need of showing who is supporting, backing up and securing the service, no offense to "Chio" (the fact I don't even know his name also adds to what I'm saying) but we are talking about big business here and there is a SERIOUS need to have what I said in order to gain full industry support.

You should buy a top banner spot on GFY, or if you can afford buy the whole skin. Big Title: EPASS ALTERNATIVE IS HERE!

This seems like very exciting news. I'll be happy to add this as a payment method at MojoHost once everything is in it's final state and launched.

Brad

I think at least where GFY is located you cant do stuff like that (and in Europe you sure as hell cant...) :winkwink:

Normally I'd say that skinning GFY is for bros but with an Epass alternative I think it would be a fitting sponsorship to generate proper awareness.. if they had the guts to just launch it as an epass alternative in phrase..

Brad

The xml api is over ssl on our side, this means that even if the stream is intercepted by a "hacker" during its transit the contents would be encrypted anyway. Using SSL encryption means that if the stream were to be intercepted the person intercepting would require private keys to be able to decode the information, and consequentially the passed username and password. This could potentially take years to crack and, during that time, we'd hope that your passwords would be updated for your own security reasons.

This is certainly a feature we could implement, or even issuing private key pairs to establish direct secure connections to us rather than using SSL over HTTP... but we feel HTTPS does cover the requirements for security in this case. If this is something that does really concern you though we'll be happy to discuss it further and try to come up with a solution that fits better with your needs.

In regards to the XMLAPI.

SSL pretty much nullifies man in the middle attacks so that's not the "hole" in the xml api format. The hole is that the code on your server, needs to contain your username/password. The more likely scenario is that a hacker cracks into your code and grabs the file with that info. They now can log into your account and send themselves money for example. An access key that is only usable for the XMLAPI is much less sensitive if it does indeed get compromised. I just see this as an issue with a lot of adult webmasters not being security gods.

The two other advantages, is companies that contract out their development again don't have to give their account number to consultants. (You'd give a consultant your ePass id, but not your PayPal username and password to set up your site).

And the advantage that I'm interested in personally, it allows software providers of shopping cart solutions or other services to perform billing on behalf of verified charge customers safely.

For example say I have a downloadable video service where I handle everything for 3rd parties. You simply have to give me your VerifiedCharge info, and purchases are automatically credited to your bank account. This same scenario holds true for shopping carts and the link. If the info required is a token, then you're probably fairly willing to grant me access to that. (This is what Paypal does for shopping cart integration). If the info is your username/password that grant full access to your account, it seems like a large safety risk.

Anyhow, just a thought which I think would add some business options and beef up your security.

To implement simply add a field called "xml-token" to the database for each merchant. When the merchant account is created auto-generate a GUID and insert it. Display this GUID to the user and give them the option to re-generate it.

When an XML API request hits your server, have them pass the username/xml-token instead of username/password. Your code instead of doing a username/password lookup in the db, you lookup username/token.

Oh one last thing.

In your API I can simply pass username/password pairs to your service until the XML returned says OK. Thus if I know your username, I can make guesses at your password via an automated password guesser program until I find it. Once I have that, I can go to town on your account. Some studies have shown that average passwords can be cracked with dictionary attacks in a matter of minutes. GUID's on the other hand are effectively impossible to guess.

Anyhow I just had my access to the XML API approved so I'm gonna go test drive it.

Service looks great so far!

bump.......

bump:upsidedow

This is awesome

Looks promising :)

wonderful!
wish ya all the best :D

Good news, look forward to checking this out!

Bump :thumbsup

Interesting

Just thought I'd post a quick review of my experience so far with Verified Charge. I'm using the XML API, and have a .NET development environment (keep the uproar to a low PHP people).

Account signup was trivial, the site looks good and easy to navigate, there are some incomplete areas but the core functionality looks to be there. A full support ticket system is functional and in place.

I hooked up the XML Pay API with the intention of using it for Single Purchases and this took literally less than 5 minutes. The transactions failed however and I finally re-read the documentation which stated I needed to open a support ticket to get the API enabled.

The test transactions worked flawlessly and returned in a matter of seconds.

I then tried out a number of live transactions. The transactions generally took around 30 seconds to process. Card#, Expiration Date, CVV checking and basic AVS all seemed to be in order (I tried variants of my information to see how loose it was).

Support time has been great and they've been proactively contacting me, even sending my account a message based on a thread I posted on GFY. (They implemented the GUID thing I discussed in the thread above in 1 day, which was very cool).

Anyhow the experience has been great so far.

this look very interesting i might give it a try.. it's nice with an alternative to epass

Thanks for the kind words.

I'll take this post to mention that we should have full debit card support (including international support) within 3 weeks. We are finalizing some details as we speak.

Thanks to everyone so far for the feedback during beta and your support.

As always if you have any questions please contact me via ICQ as I am not on GFY as much these days with everything that's going on.

Full card support (including international cards) are to be available within 2-3 weeks. Currently withdrawal by check, wire, and ACH (for US based users) is available now.

If anyone has any questions feel free to contact me via ICQ (in location)

Bump for the END of ePassporte.

Chio, am I wrong in thinking I should sign up for an affiliate account rather than the account created under the "Send Money" tab?

What are the differences between those two type of account?
(I'm thinking a lot of affiliates want to be able to receive sponsor payments from the get-go, and the "Send Money" tab's page indicates it's for "person to person payments"...)

Or is the affiliate account more for those who want to send You new clients for commission?

Thanks!

The send money tab is the correct sign up page for our epass/paypal type system account.

Please keep in mind the epass/paypal alternative will have it's own site once we fully launch (if you'd like a sneak peek icq me) but don't worry both sites are tightly integrated and you will not have to resignup.

If you have any questions contact me on ICQ in the AM. I'm heading off to bed for now.

Nice!

Thanks man, no further questions at the moment.
Just wondering if I should harass those I affiliate with to offer payouts through the coming system.. :winkwink::thumbsup
(but I'm guessing many are already realizing what an impact Your stuff will have).

bump bump

Looks awesome Chio...will be investigating today :thumbsup

Chio sended you icq please respond

FUCK EPASS ..bump

Sorry I've missed this we've been very busy as you can imagine. We are currently based in the US and UK and as we grow hope to expand our presence to other regions. Currently we are focusing on the epass/paypal system and getting that live while we await pci and cisp certification for the merchant side.

If you have any questions please contact me on icq as I am not able to check these threads too often and I don't want people waiting for answers.

Good answer! Shouldn't kimmykim know what PCI standards are?? What the heck is PCS.

Why is it still in Beta and why is there hardly any promotion for it?

Very intresting

Awesome. Great work Chio. :)