Kryptronic Software Support Forum

I have launched several sites, and all of them are very happy with auth.net

add on.. I see Authorize.net is BBB as well, so that may work.  So I'd like to again ask if it can be implemented in the checkout so that the process is seamless. That is, custoemr enters card info on my site and remains on my site during the card verification process?

Hi Dave,

I have PP Website Payment Pro (Canada). Maybe I don't have my checkout set up correctly?

This is the service I use with PP

https://www.paypal.com/ca/cgi-bin/websc … o-overview

I do have a PP merchant account. Ok, I'll have to look and see what PP gateways I have enabled.

So I looked and:

PayPal (Standard Method) - Payment Form is set to True (1).
PayPal (Pro Express Method) - Payment Form is set to True (1)
PayPal (Pro Direct Method) - Secure Server is set to False (0)

I do not show a "PayPal (Payflow Pro) - Secure Server".

Yes, I'll keep the mail and call options. So you recommend I enable Pro Direct Method and disable the other two. My thought on that is to keep at least one PP option for those who want to pay with their PP account. There seems to be a percentage of the customer base who do not want to divulge their cc# but are willing to use their PP account.

Sound right?

Dave,

Thanks for all your help and PROMPT replies. I will enable Pro Direct Method. This will replace option #1 on my original list to allow me to get away from all of the manual processing of cards.

I agree on the confusion of offering to send them to PP (option#4 on my original list) and the PP express button. I'll probably eliminate the express button now and just leave them the PP (option#4) for those that want to use PP. If this new direct method works smoothly and I see it is the dominant choice by customers, I'll probably drop the PP option. IF a  customer wants to pay with PP I could always send them an invoice via the PP interface.

Now in the PP Standard Method Gateway,it looks like this.

Active status: 1
Gateway URL type: External URL Reference
Field Display Text: "To pay with ....blah blah blah..."
Field Display Order: 4
Response Field Name: Response Code: payment_status
Response Field Name: Order Number*: item_number
Request Field Name: Oder Total*: a1
Response Codes*: Completed, Pending
Referring URL String*: paypal
Transaction Key/Password: (empty)
Gateway User/Store ID*: (my PP userid)
Perform Post-Order Updates: True (1)
Supports Recurring Billing: True (1)
Form Display Code*: (no changes made)


So for the gateway 'paypalprod' named  "PayPal (Pro Direct Method) - Secure Server" I currently have this:
Active status: 0
Gateway URL type: Internal URL Reference
Field Display Text: "Purchase using your credit card."
Field Display Order: 9
Response Field Name: Response Code: pro_payment_status
Response Field Name: Order Number*: pro_item_number
Request Field Name: Oder Total*: Order Total
Response Codes*: Completed, Pending
Referring URL String*: ccp0.php
Transaction Key/Password: (empty)
Gateway User/Store ID*: (my PP userid)
Perform Post-Order Updates: True (1)
Supports Recurring Billing: True (1)
Form Display Code*: (no changes made)

So do I make these changes"
Active status: 1
Field Display Order: 1

I have a bit of a complication with this new change. My current payment options offered are:

Payment Method Selection*
Select your method of payment.

1. We accept credit cards: VISA, MC, A/E and DISC cards.
2. Purchase by mailing a money order. Sorry, no personal or company checks, they take too long to clear the bank.
3. Let us call you so you can provide your card information. Using this method we can only accept Visa and MasterCard.
4. PayPal accepts credit cards VISA, MC, A/E and DISC cards.

Option 1 uses gateway: PayPal (Pro Direct Method)-Secure Server.
Option2 uses gateway: PayPal (Standard Method) - Payment Form.

Problem I see is with option 1. I just had a customer who could not use his Discover card. So he had to start over, create a new order and go through PayPal. Even then he said he got error messages, something about missing paramenters. So when he called, I looked in the store and it showed he created 4 different orders, but one the order using PayPal was successfull since I got the emails of payment. But it was confusing for the customer.

Now, let me say that with my version of PP's service, when I use the Virtual Terminal I am only authorized to process V and MC cards. I can't do AE or D cards. That's the rules as I understand them with PP. So I am now wondering if those restrictions still apply for the new gateway PayPal (Pro Direct Method)-Secure Server I implemented earlier today.

If that is the case, then I'll have to change how I offer the payment options. Meaning I'll have to remove AE and D from the PayPal (Pro Direct Method)-Secure Server gateway code. AE and D cardholders will still have to go to PayPal site. Taht kinda sucks because I was hoping to eliminate that from happening.

So, the PayPal (Pro Direct Method)-Secure Server will reduce my work load by processing the V and MC card payments but I was hoping it would cove AE and D too.

By chance would I be missing a setting not enabled or something like that?

Thanks.

CrownRoyal wrote:

So for the "Gateway URL Type" should I change them to "internal"? Does it matter?

You do not want or need to change that field.

I sort of figured I had to do that. Thanks Dave for your help.

As I said, you do not want or need to change those. Their meaning is exactly as it appears. The direct method is handled internally by CCP itself and the payment form is handled externally by PayPal not CCP.

Site search engine tweaked? Sounds like a new thread might be needed.

I might start a new thread on the search engine. I can think of a few recommendations.

Regarding auto-emailing drop shippers (DS), I started out doing that but ended up canceling that feature. Now all orders come to me and then I forward them on. You see, a customer may buy 3 items and each item comes from a different DS. Yes, the software will direct the correct orders to each DS but there were bits of info in those emails that the DS did not need/want to see.

Example 1, an option to an item might include the purchase of an accessory item related to the product. In this case, it would be something the DS needed to know about in order to ship. There are other options I have set up to reflect extra shipping for bulky items. The DS doesn't need to know about that. So its not like I can remove code to not show options in the emails.

The way which we handle our inventory is quite mixed, its not a one fits all setup. Luckily a lot of what we sell is considered flat mail (paper documents) so its not really a struggle. But with 17 DS'ers, there has to be some flexibility.

Items that sell and we carry here in inventory has to have the inventory count controlled and shipping is based on weight.
Items that sell and are carried by DS'ers does not have inventory count controlled and shipping is based on flat rates (they are all different) with exception to some DS'ers who charge per time as well. I have the custom shipping methods control that. And some items, from some DS'ers, have additional shipping charges because they are heavy to ship. Thus the Example 1 mentioned earlier.

I could resolve that by eliminating the bulky shipping charge and just add it to the retail price but that then makes the product's pricing uncompetitive.

Then of course there are the order changes. A customer forgets to add an item, wants to change an item etc. If the orders with auto emailed to the DS, I'd have to chase them down, find the order, make the changes, a real headache. And some DS process and ship orders within the hour when done through the business day.  In the end, I decided it was better to finalize an order, then send it on to a DS if needed.