Please note: We are using Magento's Professional Edition which does not come with Vendor Support.
I've looked over previous questions, and while I can find questions and answers about multiple payment gateways on a site, I can't find anything about Magento's Payment Bridge specifically. Payment Bridge is a PA-DSS certified application that Magento provides with it's Enterprise and Professional licenses. It's necessary for a PCI compliant environment.
Our problem is that our client has two Auth.net accounts. This is for reconciliation and the explanation can get long-winded, so please just trust me that this is a necessary scenario.
When creating the merchant with the Merchant Configuration tool when setting up Payment Bridge, it only allows you to provide one login, i.e. just the one account, and it asks which cards are accepted. The site will accept all cards, but one account handles Visa, Mastercard, and Discover, while the other handles all Amex payments.
How can I set up the merchant during the Payment Bridge set up to be able to have both accounts?
Update - for now, we've created a hack in the Payment Bridge Authorize.net class that checks the card type and, depending on the type, it switches the credentials if need be.
Not a perfect solution, I realize, but it's working while we figure out something a little more stable.
If you have any ideas, please share!
Thanks.
Related
I realize that Omnichannel is currently only associated with the Customer Service module for 365. However we have had a request from a client to provide Omnichannel for a sales process on a web site which links into a sales CE 365 organization (so in other words an agent to guide the user through the sales process via a chat if need be).
Is it possible to add in the Omnichannel module for sales in any way and if not any sort of alternate solutions we could follow for this requirement?
No, Omnichannel is built on top of Customer Service so having this first-party app installed is a requirement detailed in the documentation. I recommend you to contact your MS Account Manager and discuss this topic with them as depending on your requirements you might also need Power BI/Customer Voice/Power Virtual Agent licenses as well so maybe it's worth to explore some cross-application licensing.
There're alternative solutions in AppSource like CafeX LiveAssist and a few others, please make sure you filter by application to make sure they will work with Sales.
I try to integrate our test system with SagePay. But I've found lot of different apis and documentations for integration. I'm bit confused about it. Could you tell me which api version is most up to date and suits my needs?
I want to have recurring payment functionality without CVV resubmit.
System will be designed to work on US market.
This api have functionality which I want and it's also mentioned in some answers on stackoverflow
https://test.sagepay.com
This api is very easy to use, but I don't see recurring payment functionality (only with CVV resubmit)
https://developer.sagepayments.com
There is another set of documents for integration, based on .vsp services
www.sagepay.co.uk/support/integration-kits-protocols-document
I suppose some of those apis are legacy and are maintained for some old integrated systems. It would be great if documentation for those apis were gathered in one place and explained.
Sage Pay UK and Sage Payment Solutions(US) operate independtly to each other with different integration methods and API's. www.sagepay.co.uk/support/integration-kits-protocols-document relates to Sage Pay UK only.
I am using the Plaid API for iOS to write a program which accesses banks accounts after authentication and displays the transaction data.
I need to know if it's possible to transfer funds between accounts (checking to savings) and how.
I know acorns uses the same API, and they are able to transfer funds, and Plaid's site claims "Authorize ACH payments in seconds based on the information users know in their heads. No need to know account or routing number. No need for micro-deposits."
But is there documentation on how to move money on the site?
Plaid does not move money via their API.
UPDATES
Dwolla now provides a white-label solution that basically does this all for you. Combine Plaid and Dwolla, and you're basically golden for payments in the US now.
Disclaimer: I co-founded a company that is a customer of Dwolla and one of their first white label customers.
Original content
Moving money with the credentials that Plaid provides requires using the Automated Clearing House (ACH) process in the US.
What won't work
Ripple Labs (currently under federal investigation), Dwolla, BitPay, etc. all require proprietary authentication with their own platforms before they will move money. You can't use them with the routing and account number that you get from Plaid. You have to adopt their entire system...or nothing.
What will work
Plaid's API provides more for you than those other APIs because you have the routing and account number. This allows you to directly enter into the ACH system yourself. All you need to move money is the senders routing and account number, the receiver's routing and account number, and the amount. Plaid gives you 2/5 of this already.
But you need to move the funds. Using an ACH processor (like Vericheck - I was a customer), you can use their API to send money to an account. Or a bank (like Silicon Valley Bank - also was a customer), where you can generate and upload a NACHA file with the instructions.
What you're in for
Compliance and banking laws are strict. Get a good lawyer to help explain what you're up against. ACH processors will want to do comprehensive background checks on you and your business. Banks will require you to deposit a portion of your proposed transactions to cover STOP payments (when a user tells their bank to cancel a payment, like voiding a check). You may have to register as a money transmitter (a small $1M in filing, registration, and legal fees for all 50 states).
Moving money is still difficult to do on behalf of a user, but if you're willing to put in the legal work, the programming is pretty simple!
Plaid's API actually will give you routing and account number information and/or transaction data with cool info like GPS coordinates of transactions but I believe when I spoke to them they explicitly said that they don't provide money moving services in their API.
I've been looking at Ripple Labs, Dwolla, BitPay, etcetera.
If you have any recommendations about getting Plaid and Meteor working well together, then I can add you to a Cloud9 workspace and would be delighted to learn. :)
Plaid recently signed an agreement with Stripe. Stripe allows you to move funds via ACH through their newly realeased API: https://stripe.com/blog/accept-ach-payments
This is very similar to what companies like Peloton Technologies Inc. have been doing in Canada for EFT since 2010. EFT is what most parts of the world refer to as ACH.
Plaid provides Stripe with a higher possibility of being able to instantly verify a bank account, otherwise they fall back to the old Paypal 4 day verification processes of issuing a couple of transfers and waiting for the users to verify the amounts.
The pain of waiting on the user and the fact that 7 out of 10 times a bank account is entered wrong is what has probably prevented Stripe and other companies entering this space until now.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
Magento is a great product but out-of-the-box it really lacks recurring billing support. I've come to a crossroads with my current project and need some direction.
We have exhausted every Google search and module that is under the sun for Magento to support recurring billing the way we need it to. So far, all we have come across is one module that costs $300 by aHeadWorks in the UK. We've tried the module and are extremely disappointed so far, mainly just due to total lack of support and documentation; Nobody seems to have the knowledge to answer our questions, or even attempt to.
Our goals are simple and we cannot figure out why there aren't more solutions out there to do this, so the question becomes, what is everyone else doing?
All we need to do is the following:
Provide subscriptions for items such as web hosting, text message marketing, etc.
Tie into our merchant account and authorize.net
Keep the customer on our site at all times
Skrill Moneybookers & their module isn't compatible with what we need to do (at least in the US). PayPal sucks and wants to hold our money back and also wants to redirect customers to their site to setup a billing agreement. iTransact services are fantastic but there is one module that is 2 years+ old and has no support.
The answer is recurring billing is quite a taboo in the e-commerce industry. This is mostly because the big boys, i.e. Mastercard and Visa have very strict rules governing recurring billing transactions.
Recurring billing means storing a customer's credit/debit card data, long number, expiry, and cvv2, for future processing. However, this opens up a huge can of worms in terms of security. This is why Visa/Mastercard impose rules on merchants in becoming PCIDSS compliant. Practically this means your server/website have to be certified to be secure, using a service like McAfee PCIDSS, which basically scans your server/website remotely and attempts to break it. It looks for open ports, badly configured firewall (or lack of), xss scripting flaws, mysql injection breaches, operating system security breaches, and many more. One of the most important elements with PCIDSS is having all card data encrypted.
It is a laborious process, since once you are given a report, you are also expected to repair all flagged critical issues and pass the scan. There are other steps to complete, but I shan't enumerate them all here. See the pci dss website for reference. You are also expected to keep the certification up-to-date on a quarterly basis.
Basically what this means is that Visa/Mastercard don't particularly like the smaller merchants to have this feature, as they can be of major risk to clients. If their system is breached, hackers could use the card data for criminal enterprises.
This in turn means Visa/Mastercard favor the big players in the industry to handle recurring billing, such as PayPal, Worldpay, authorize.net, etc. One port of call, one entity to fine and recover losses if there's a problem.
And now we return to Magento. Whilst it is relatively easy to create a normal payment method in Magento, since most PSPs work in the same manner [mostly], recurring billing is handled differently from provider to provider. Furthermore, some are more restrictive than others.
I can't and won't recommend PayPal as I have had extremely bad experiences with them, I can definitely recommend Worldpay + Futurepay + Invisible XML method. You would need to hire a Magento developer to write a custom module for you, but it's doable. I am currently writing a module for a client in Norway using a norwegian payment method and recurring billing.
If you still need help, get in touch, I can write a module for your store.
Hope this helps.
Cheers,
Michael.
Paradox Labs has an Authorize.NET CIM extension that supports Magento Recurring Profiles and Braintree recently released an extension that also supports them. I have made lots of improvements to Magento's recurring profiles. You can definitely tell they are in beta form, but that should stop you from getting your hands dirty and finishing things that the Magento team hasn't got to yet.
Here are a few things I improved:
https://github.com/tegansnyder/Magento-Recurring-Beta-Grid-Improvements
https://github.com/tegansnyder/Magento-Programmatically-Create-Recurring-Profiles-Authorize.net-CIM
https://gist.github.com/tegansnyder
I'm had to make modifications to the cart controller to allow discount codes to display on the frontend when used on nominal items. By default they wouldn't display that they were applied.
I also had to make some modifications to the daily billing job that runs to remove the discounts the second time the profile is billed. Magento was applying them each time it reached the end of cycle.
Lots of little things here and there, but it's getting there.
You should look at the service OrderGroove.com. They specialize in recurring orders in e-commerce systems like Magento.
There are different strategies to implement recurring billing / product subscriptions with Magento:
Magento Recurring Profiles
Magento's built in recurring profiles feature can be used with compatible Magento payment extensions and gateways. These include PayPal, Authorize.Net CIM (Customer Information Manager). A payment extension which supports the recurring profiles feature is required for this approach, for example Paradox Labs CIM Extension.
Customize Magento to Support Recurring Billing
This can be done with a third party extension, like the (AheadWorks SARP extension) or developed from scratch.
Integrate External Subscription Management Software
Platforms which specialize in eCommerce product subscriptions include:
Subscribe Pro
Order Groove
Some subscription management software for digital goods includes:
Recurly
Zuora
I understand how NFC is supposed to work on a high level, and a bit about the protocols used. Now, I need to understand, with your help, if there are any standards related to mobile payments.
From a trusted service manager perpective, I believe there are no standards at all and that both the machine on the point of sale and the app on the mobile device would have to be custom made correct?
If no such standards exist yet, can I assume it can be as "simple" as:
On contact the machine creates a checkout receipt and sends it to the device (this would have to be done with customized hardware)
The device receives the receipt and uses the UICC to authenticate itself with the bank/TSM
The bank, upon validation, signs the receipt which is forwarded to the machine by the device
Am I getting this right? If there are any technical bits I'm missing, please refer them so I can research.
Thanks
sure there are standards - see EMV (Europay, Mastercard, Visa). It is necessary for world wide interoperability of the payments systems, which uses the chip (aka secure element), no matter they are contact or contactless (i.e. NFC).
EMV specifies used hardware, protocols, file structures and used commands, data authentication, PIN ciphering, key management. It is pretty complicated.
I think you can start here: http://en.wikipedia.org/wiki/EMV
Regards,
STeN
www.mautilus.com
As said before, EMVCo standards will cover some of your need, but so will also GlobalPlatform underlying technology, as well as some further refinements of AEPM.
I'll also add once you obtain the information you need from the payment card, you have to send it to a payment gateway which then transfers the information to the payment network (Visa, MasterCard, etc.) where the data will then be routed to the issuer of the card for authorization. The response is then sent all the way back through the chain to the initiator of the transaction. Triangle has a free API that captures the card information for you. You can then use the captured information and route it to your gateway.
Disclaimer: I'm the co-founder of Triangle.