Payment Method Feature Support

TABLE OF CONTENTS

Introduction

This article gives an overview of what feature each Payment Method supports.

Credit card - Card Connect

Adding/Managing a new payment method

  1. Adding a payment method from Admin >> Payment Methods >> Add New

    1. General Settings

      1. All the standard fields available in this section should be available for all the payment methods and should work in the same way irrespective of the added payment method

    2. Merchant Gateway Settings

      1. Add a new option Card Connect for the Select A Gateway field.

      2. When the Card Connect option is selected for the Select A Gateway field, this section displays only those fields which are required to connect Card Connect merchant account with Znode application along with the generic fields (except the Accepted Cards field) which are available for all the payment methods like:

        1. Credit Card Authorization

        2. Display Capture In OMS

    3. The generic fields have the same behavior as those available for other payment methods.

    4. Admin users should be able to submit the required information to add a Card Connect payment method in Znode.

  2. Managing Card Connect payment method from Admin >> Payment Methods >> Edit

    1. Admin users should be able to update all the necessary information for the Card Connect payment method except for the following:

      1. Select A Payment Type

      2. Payment Code

      3. Select A Gateway

  3. Using Card Connect in the admin application and web store

    1. After the Card Connect payment method is associated with Store(s) or User Profile(s), it should be available for making payments while creating an Order from the admin and web store, while managing an Order, and while converting a Quote to an Order.

    2. The workflow considered to display/hide payment methods for specific users for different stores versus user profile scenarios for other payment methods should also be considered for the Card Connect payment method.

Payments using Card Connect

  1. Adding a new card for making payments

    1. After selecting the Card Connect payment option, if no card is saved for the user account, then an iframed section to add the card details should appear along with Save this credit card for future use field outside the iframe.

Note: Save this credit card for future use field should be displayed only for Orders which are placed or are being placed for registered users and for Quotes.

  1. The iframe should load the Card Connect payment section which can be used by admin users or customers (shoppers) to add card details that can be used to make payments while placing/managing an Order or while converting a Quote to an Order from the admin application or web store.

  2. When card details are added to the Card Connect iframe, a token should be generated. If a user selects the Save this credit card for future use field, the last 4 digits of the card along with the token (or Account/Profile ID whatever is provided by the gateway) should be saved in Znode so that the card can be used for making future payments.

  3. Selecting a saved card for making payments

    1. After selecting the Card Connect payment option, if at least one card is saved for the user account, then a section to select a saved card and another section to add the payment details should appear.

    2. Admin users or customers (shoppers) should be able to select a saved card to make payments while placing/managing an Order or while converting a Quote to an Order from the admin application or web store.

    3. The saved last 4 digits of the card and the generated token (or Account/Profile ID whatever is provided by the gateway) should be used to make payments via Card Connect.
      Note: When a section to add new card details is selected, the application should work in the same way as described in point 1.

  4. Scenarios of payments from admin application and web store

    1. The workflow considered for other payment methods for scenarios when card details are correct/incorrect, merchant details added for the payment method are correct/incorrect, a voucher(s) is applied to an Order, “Order Total - Voucher Amount” increases due to any changes, card details are saved/not saved for future use, etc should be considered for the Card Connect payment method as well.

Allow Authorize payment Only for card connect

While creating payment if we select ‘Credit Card Authorization’, then the order will be ‘Pre-Authorize Transactions Without Capturing’ (Payment status will be authorized).  Admin has to manage the order and change its payment status to capture successful Transactions.

Allows Authorize and Capture

While creating payment if we do not check ‘Credit Card Authorization’ (Payment status will be captured), then the order will be placed with successful Transactions (authorize + capture).

Allow refund from return

  1. Refunds should be initiated back to the used card via Card Connect when changes are made to Order (which uses Card Connect payment method) which reduces “Order Total - Voucher Amount” and when a refund is processed for a Return whose “Return Total - Voucher Amount” is greater than $0 (currency may change)

Note: Before version 9.7 Order Total was calculated and displayed after deducting the Voucher Amount and from version 9.7 Order Total and Voucher Amount are displayed separately. Therefore, depending on the version, in this gateway is being implemented in, the value of “Order Total - Voucher Amount” is considered accordingly.

  1. Scenarios of refunds from admin application and web store

    1. The workflow considered for other payment methods for scenarios when a voucher(s) is applied to an Order/Return, “Order Total - Voucher Amount” reduces due to any changes, the refund is processed for a Return whose “Return Total - Voucher Amount” is greater than $0 (currency may change), Order is not captured when a user tries to process the refund, etc should be considered for the Card Connect payment method as well.

    2. Note: Before version 9.7 Order Total was calculated and displayed after deducting the Voucher Amount and from version 9.7 Order Total and Voucher Amount are displayed separately. Therefore, depending on the version, in this gateway is being implemented in, the value of “Order Total - Voucher Amount” is considered accordingly.


Automated Clearing House

Adding/Managing a new payment method

  1. Adding a payment method from Admin >> Payment Methods >> Add New

    1. General Settings

      1. Add a new option ACH Payment under the Select a Payment Type field

      2. When ACH Payment method is selected hide billing address field will be hidden

      3. All the other standard fields available in this section should be available for all the payment methods and should work in the same way irrespective of the added payment method
        Note - For future only if ACH is provided by other payment gateways other than Cardconnect

    2. Merchant Gateway Settings

      1. Select A Gateway field options will have all the existing options but for now this ACH payment to work it will be mandatory to have the Card Connect option selected within it (As this implementation is specifically for Card Connect only)

      2. When the Card Connect option is selected for the Select A Gateway field, this section should display only those generic fields which are required to connect Card Connect merchant account with Znode application which are:

        1. Select Gateway Mode: Test Mode and Live Mode

        2. User Name

        3. Password

        4. Merchant Id

      3. The generic fields have the same behavior as those available for other payment methods.

    3. Admin users should be able to submit the required information to add a Card Connect ACH payment method in Znode.

  2. Managing ACH payment method from Admin >> Payment Methods >> Edit

    1. Admin users should be able to update all the necessary information for the Card Connect ACH payment method except for the following:

      1. Select A Payment Type

      2. Payment Code

      3. Select A Gateway

  3. Using ACH payment in admin application and web store

    1. After the Card Connect ACH payment method is associated with Store(s) or User Profile(s), it should be available for making payments while creating an Order from the admin and web store, while managing an Order, and while converting a Quote to an Order.

    2. The workflow considered to display/hide payment methods for specific users for different stores versus user profile scenarios for other payment methods should also be considered for the Card Connect ACH payment method.

Payments using ACH

  1. Adding Banking information for making payments

    1. After selecting the ACH payment option, if no bank information is saved for the user account, then a section to add the banking details should appear through the iframe with the Account Number/Routing Number field(Mandatory field) along with Save the payment details for future use.

Note: Save the payment details for future use field should be displayed only for Orders which are placed or are being placed for registered users and for Quotes.

  1. The Card Connect ACH payment section can be used by admin users or customers (shoppers) to add bank details that can be used to make payments while placing an Order or while converting a Quote to an Order from the admin application or web store.

  2. When banking details are added to the Card Connect ACH payment section, while adding the number will be displayed as 12345/****6789 , and a token should be generated. If a user selects the Save the payment details for future use field, the token (or Account/Profile ID whatever is provided by the gateway) should be saved in Znode so that the banking details can be used for making future ACH payments.

  3. Selecting saved banking details for making payments

    1. After selecting the ACH payment option, if at least one banking detail is saved for the user account, then a section to select a saved banking detail and another section to add the banking details should appear.

    2. Admin users or customers (shoppers) should be able to select a saved banking detail to make payments while placing an Order or while converting a Quote to an Order from the admin application or web store.

    3. The saved last 4 digits of Account/routing number  (It can be displayed as for example Account number/Routing number: ******1241, depending on the number of digits accepted in the account number/routing number filed) and the generated token (or Account/Profile ID whatever is provided by the gateway) should be used to make ACH payments via Card Connect.

  4. Scenarios of payments from admin application and web store

    1. The workflow to check bank details are correct/incorrect, merchant details added for the payment method are correct/incorrect, a voucher(s) is applied to an Order, “Order Total - Voucher Amount” increases due to any changes, bank details are saved/not saved for future use, etc should be considered for the Card Connect ACH  payment method.

Important Note - 

  1. There is no authorized transaction in ACH, payment will be directly captured.

  2. No implementation of a refund with the return.

Credit card - Braintree

Adding/Managing a new payment method

  1. Adding a payment method from Admin >> Payment Methods >> Add New

    1. General Settings

      1. All the standard fields available in this section should be available for all the payment methods and should work in the same way irrespective of the added payment method.

    2. Merchant Gateway Settings

      1. When the Braintree option is selected for the Select A Gateway field

        1. This section should display only those fields which are required to connect the Braintree merchant account with the Znode application along with the generic fields which are available for all the payment methods (existing behavior).

        2. Remove the Accepted Cards field only for the Braintree gateway.

        3. General Info: Znode has no control over the elements displayed on the hosted field page therefore while creating/managing such payment method, irrespective of the value selected for the Accepted Cards field, the acceptable options would load considering the gateway’s merchant account settings.

      2. The generic fields should have the same behavior as those available for other payment methods.

    3. Admin users should be able to submit the required information to add a Braintree payment method in Znode as per the existing behavior.

  2. Managing Braintree payment method from Admin >> Payment Methods >> Edit

    1. Admin users should be able to update all the necessary information for the Braintree payment method as per the existing behavior.

  3. Using Braintree in admin application and web store

    1. After the Braintree payment method is associated with Store(s) or User Profile(s), it should be available for making payments while creating an Order (normal order or Pending Order or Pending Payments order) from admin and web store, while managing an Order, and while converting a Quote to an Order as per the existing behavior.

    2. The workflow considered to display/hide payment methods for specific users for different stores versus user profile scenarios for other payment methods should also be considered for the Braintree payment method as per the existing behavior.

Payments using Braintree

  1. Adding a new card for making payments

    1. After selecting the Braintree payment option, if no card is saved for the user account, then a section to add the card details should appear.

    2. The new payment page rendering the hosted fields should load the Braintree payment section which can be used by admin users or customers (shoppers) to add card details that can be used to make payments while placing/managing an Order or while converting a Quote to an Order from the admin application or web store.

    3. When card details are added to this page, all the necessary information related to the card is stored within this hosted field page itself which is in contrast to the other payment options wherein an explicit setting for saving the card detail is provided

  2. Selecting a saved card for making payments

    1. After selecting the Braintree payment option, if at least one card is saved for the user account, that will be seen on this hosted filed page as which will be selected by default but if multiple cards are there then the user will have the option to choose among them.

    2. Admin users or customers (shoppers) should be able to select a saved card to make payments while placing/managing an Order or while converting a Quote to an Order from the admin application or web store.

    3. The last 4 digits of the card will be saved. As well once the user chooses the card to pay with there is no need to input the CVV as well for the same which again is in contrast with the previous Iframe integrations wherein CVV was to be entered even for the saved cards

    4. Note: When choosing another way to pay is selected, the application should work in the same way as described in point 1.

  3. Scenarios of payments from admin application and web store

    1. The workflow considered for other payment methods for scenarios when card details are correct/incorrect, merchant details added for the payment method are correct/incorrect, a voucher(s) is applied to an Order, “Order Total - Voucher Amount” increases due to any changes, etc should be considered for the Braintree payment method as well.

Allow Authorize payment Only for card connect

While creating payment if we select ‘Credit Card Authorization’, then the order will be ‘Pre-Authorize Transactions Without Capturing’ (Payment status will be authorized).  Admin has to manage the order and change its payment status to capture for successful transactions 

Allows Authorize and Capture

While creating payment if we do not check ‘Credit Card Authorization’ (Payment status will be captured), then the order will be placed with successful Transactions (authorize + capture). 

Refund using Braintree

  1. Refunds should be initiated back to the used card via Braintree when changes are made to Order (which uses the Braintree payment method) which reduces “Order Total - Voucher Amount” and when a refund is processed for a Return whose “Return Total - Voucher Amount” is greater than $0 (currency may change)

Note:  Before version 9.7 Order Total was calculated and displayed after deducting the Voucher Amount and from 9.7 Order Total and Voucher Amount are displayed separately. Therefore, depending on the version this gateway is being implemented in, the value of “Order Total - Voucher Amount” is considered accordingly.

  1. Scenarios of refunds from admin application and web store

    1. The workflow considered for other payment methods for scenarios when a voucher(s) is applied to an Order/Return, “Order Total - Voucher Amount” reduces due to any changes, the refund is processed for a Return whose “Return Total - Voucher Amount” is greater than $0 (currency may change), Order is not captured when a user tries to process the refund, etc should be considered for the Braintree payment method as well.


Credit card - Authorize.net

Adding/Managing a new payment method

  1. Adding a payment method from Admin >> Payment Methods >> Add New

    1. General Settings

      1. All the standard fields available in this section should be available for all the payment methods and should work in the same way irrespective of the added payment method

    2. Merchant Gateway Settings

      1. When the Authorize.Net option is selected for the Select A Gateway field

        1. This section should display only those fields which are required to connect the Authorize.Net merchant account with the Znode application along with the generic fields which are available for all the payment methods (existing behavior).

        2. Remove the Accepted Cards field only for Authorize.Net gateway.

        3. General Info: Znode has no control over the elements displayed in the iframe therefore while creating/managing an iframe-based payment method, irrespective of the value selected for the Accepted Cards field, the acceptable options would load considering the gateway’s merchant account settings

      2. The generic fields should have the same behavior as those available for other payment methods.

    3. Admin users should be able to submit the required information to add an Authorize.Net payment method in Znode as per the existing behavior.

  1. Managing Authorize.Net payment method from Admin >> Payment Methods >> Edit

    1. Admin users should be able to update all the necessary information for the Authorize.Net payment method as per the existing behavior.

  2. Using Authorize.Net in admin application and web store

    1. After the Authorize.Net payment method is associated with Store(s) or User Profile(s), it should be available for making payments while creating an Order (normal order or Pending Order or Pending Payments order) from the admin and web store, while managing an Order, and while converting a Quote to an Order as per the existing behavior.

    2. The workflow considered to display/hide payment methods for specific users for different stores versus user profile scenarios for other payment methods should also be considered for the Authorize.Net payment method as per the existing behavior.

Payments using Authorize.Net

  1. Adding a new card for making payments

    1. After selecting the Authorize.Net payment option, if no card is saved for the user account, then an iframed section to add the card details should appear along with Save this credit card for future use field inside the iframe.

Note: Save this credit card for future use field should be displayed only for Orders which are placed or are being placed for registered users and for Quotes.

  1. The iframe should load the Authorize.Net payment section which can be used by admin users or customers (shoppers) to add card details that can be used to make payments while placing/managing an Order or while converting a Quote to an Order from the admin application or web store.

  2. When card details are added to the Authorize.Net iframe, a token should be generated. If a user selects the Save this credit card for future use field, the last 4 digits of the card along with the token (or Account/Profile ID whatever is provided by the gateway) should be saved in Znode so that the card can be used for making future payments.

  3. New User (visiting for the 1st time) or when no credit card details are saved.

    1. The user selects the Payment Type as “Authorize” and clicks on the “Submit and Pay” button a modal window will be displayed where the user can add new credit card details and the details can be saved for future use.

    2. The “Save this Credit Card information for future use” this checkbox will be displayed on the same iframe but in a different section, this is required to capture the credit card details to be sent to the authorize.net for creation of a customer profile which is required for saving the credit card details for future use (refer the mockups shared for more details).

    3. Clicking on the pay button will place the final order and the respective amount will be deducted from the entered credit card.

    4. Note: The “Save this Credit Card information for future use” will be displayed out of the iframe to capture the credit card details hence two separate sections are displayed

      Note: All the details visible in the iframe cannot be modified as Authorize.net does not support customization, the details/color scheme /UI, etc will be displayed as per what is shared by the Authroize.net

  4. Selecting a saved card for making payments

    1. After selecting the Authorize.Net payment option, if at least one card is saved by the specific user, then the modal window will display the details of the saved card 

    2. Admin users or customers (shoppers) should be able to select a saved card to make payments while placing/managing an Order or while converting a Quote to an Order from the admin application or web store.

      1. When the user checks the “Save this Credit Card information for future use” the credit card details will be saved and the next time when the user tries to place an order the credit card details that were saved will be displayed in the modal window (refer the mockups shared for more details).

        1. Users can select the radio button for selecting any one of the saved credit card for placing the order.

        2. The saved last 4 digits of the card and the generated token (or Account/Profile ID whatever is provided by the gateway) should be used to make payments via Authorize.Net.

        3. Clicking on the pay button will place the final order and the respective amount will be deducted from the selected credit card.

      2. Authorize.net only provides options to save and display 4 credit card details hence the user will only be able to save 4 credit cards

      3. When a user does not check the “Save this Credit Card information for future use” then no card details will be saved and when the user tries to place another order user would need to put the credit card details again (the flow will be the same as what is defined for a new customer trying to place the order).

    3. Adding a new Card even when other cards are saved

      1. When already existing credit card details are available but the user wants to add a new credit card.

        1. When the user tries to place another order and the saved credit card details are visible in the modal window, the user will also have information to add another credit card details

        2. The user would need to click on the “Add New Payment Method” and they will be displayed with another section to add the details (the flow will be the same as what is defined for a new customer trying to place the order)

        3. Clicking on the pay button will place the final order and the respective amount will be deducted from the entered credit card.

Note: All the details visible in the iframe cannot be modified as Authorize.net does not support customization, the details/color scheme /UI, etc will be displayed as per what is shared by the Authroize.net

  1. Scenarios of payments from admin application and web store

    1. The workflow considered for other payment methods for scenarios when card details are correct/incorrect, merchant details added for the payment method are correct/incorrect, a voucher(s) is applied to an Order, “Order Total - Voucher Amount” increases due to any changes, card details are saved/not saved for future use, etc should be considered for the Authorize.Net payment method as well

  2. When an order is placed from Admin following will be the sequence of the tabs available 

    1. Customer

    2. Cart & Shipping

    3. Review

    4. Payment and Place Order 

  3. Review Tab

    1. Customer, Cart & Shipping Details will be displayed in the Review tab

    2. The payment details/section will not be available in the Review tab

    3. The review tab will only have the details visible from the Customer and Cart & Shipping tabs

  4. Payment and Place Order Tab

    1. The payment and the order will be placed in the “Payment and Place order” tab

    2. The pay button will be visible in the iframe and once the user clicks on the “Pay” button then the payment will be done and the order will be placed

  5. The above change will be applicable to all the payment methods used for placing a new order and managing an existing order (i.e when the shipping or other details are changed and then for extra payment, Authorize.net is used) from Admin screens.

Allow Authorize payment Only for card connect

While creating payment if we select ‘Credit Card Authorization’, then the order will be ‘Pre-Authorize Transactions Without Capturing’ (Payment status will be authorized).  Admin has to manage the order and change its payment status to capture for successful Transactions 

Allows Authorize and Capture

While creating payment if we do not check ‘Credit Card Authorization’ (Payment status will be captured), then the order will be placed with successful Transactions (authorize + capture). 

Refund using Authorize .net

  1. Refunds should be initiated back to the used card via authorize.net when changes are made to Order (which uses the Braintree payment method) which reduces “Order Total - Voucher Amount” and when a refund is processed for a Return whose “Return Total - Voucher Amount” is greater than $0 (currency may change)

Note:  Before version  9.7 Order Total was calculated and displayed after deducting the Voucher Amount and from version 9.7 Order Total and Voucher Amount are displayed separately. Therefore, depending on the version this gateway is being implemented in, the value of “Order Total - Voucher Amount” is considered accordingly.

  1. Scenarios of refunds from admin application and web store

    1. The workflow considered for other payment methods for scenarios when a voucher(s) is applied to an Order/Return, “Order Total - Voucher Amount” reduces due to any changes, the refund is processed for a Return whose “Return Total - Voucher Amount” is greater than $0 (currency may change), Order is not captured when a user tries to process the refund, etc should be considered for the Braintree payment method as well.

Invoice/PO

Changes on the Webstore

  1. A new action icon  is introduced in the order history section (On hovering the icon, it will read as ‘Pay Invoice’) and will be visible only against the orders whose Payment Type is ‘Invoice Me’ or ‘Purchase Order’

  2. A new button ‘Make Payment’, is added on the Order Receipt page, and also a new section reading as ‘Payment History’ is added on the same page.

  3. Note: There are also some new screens that are introduced and explanations for them can be seen in the Workflow section below.

Changes on the Admin

  1. The  ‘Payment method’ tab on the Manage store screen is to be renamed to ‘Webstore Payment Methods’ 

  2. A new tab that will read as ‘Offline Payment Methods’ is to be added in the Manage Store Screen just below the ‘Webstore Payment Methods’ tab

    1. The features/functioning within this tab will be exactly similar to how the ‘Web Store Payment Methods’ work currently with no additional implementation

    2. The difference here will that the payment methods associated with this ‘Offline Payment Methods’ Tab will be the only ones that will be available for the customers to make the Invoice payments against the order with payment type as Invoice me or Purchase Order

    3. If no payment methods are added in the Offline Payment Methods Tab, then there should be a message reading as ‘Payment Method not configured, kindly contact Admin’ on the make payment pop up under the select payment method section

  3. A new section will be added as ‘Payment History’ above the Order History section on the Manage Order screen

Workflow Webstore

  1. The Order submission workflow through the webstore will be as is it's just that in order to make the invoice payments or access the invoice feature, the customers will have to choose among Invoice Me or Purchase Order as payment method.

  2. The Customer has the option to pay for the invoices through the Order History Screen using the new icon under the action column for the orders having payment type as a Purchase order or Invoice Me only.

  3. Upon clicking this new icon against an order from the screen above, the customer will land up on the ‘Make Payment’ screen (sample for it can be seen below) where the customer will be able to view:

    1. Order Number

    2. Order Total

    3. Amount Due

    4. Payment Amount (This will be prefilled with the value of Amount Due) 

    5. Select Payment Method etc

  4. On this screen above, the customer will currently have options to pay through Credit Card and ACH, (but then there will also be an ability to add other payment methods as well which will be a future scope)

  5. If the customer selects the ACH payment method for making the payment for the invoice then the Amount in the ‘Payment Amount’ field will be editable and customers will have the ability to pay partially with the amount of their choice wherein only 2 digits will be allowed after the decimal point

  6. While entering an amount in this field there has to be a validation set in place wherein the amount should not exceed the amount available in the ‘Amount Due’ field. If in case, the customer enters an amount more than the amount present in the Amount Due field then there should be a message displayed to the customer just below the Payment Amount textbox reading as ‘ The Payment Amount cannot be greater than the Amount Due’

  7. For all the other payment methods (except ACH) the Payment Amount field will be locked i.e. the customer will not have the ability to edit the amount within this field and will have to pay the complete amount seen in this field

  8. Add on to point number 5, 6, and 7 above, customers will also have the option to pay for the amount remaining through a Credit card. But as mentioned above, if the customer chooses a credit card they can only pay the amount remaining in full with no option to make any partial payments on the amount remaining

  9. The rest of the features like Saving credit cards for future use as well as Saving payment details for future use will work as is

  10. On submitting the payment, and upon payment success, the customer will be taken to the order receipt screen (With a ‘Thank you for Submitting Payment’ at the top of the screen) similar to what we see for all the orders with an additional area within the order receipt page which is named as ‘Payments’ to track the payment history in relation to the specific order against which the invoice payment is made. This section will comprise the following columns:

    1. Date 

    2. Payment Type

    3. Status (the value here will always read as ‘ Pending’)

    4. Amount

    5. Amount Remaining (This will showcase the total amount for the order and will change based upon the payments made by the customers. For Example: Consider that when the order was placed the total amount was $1000. While making the payment for the invoice, if the customer chooses to make partial payment through ACH for say $300. So the amount in the Amount Remaining  column will be $1000 - $300 = $700 and this amount will be seen on the Amount Due field on the Make Payment Screen. This Amount  Remaining column will get updated upon every payment made by the customer against the invoice till it is ‘0’)
      Note: The format of details displayed under this section should have a consistent behavior and should not be considered from the mockup.

  1. For other payment-related scenarios like failure etc, the system will work as is with no change in its flow.

  2. As mentioned in the Changes on the Webstore point number 2, the customer also has the option to pay for the invoices through the Order Receipt Page using “Make Payment’ Button. This button will be available on the receipt page only for the orders having payment type as Purchase order or Invoice Me. 

    1. Once the customers clicks on this button, flow will be same as mentioned in this section from point number 2 to point number 9

  3. One of the important points to note here is that when the Amount Remaining column on the order receipt page has the value ‘0’, then the Make Payment button on the Order Receipt Page as well as the new pay icon on the Order History Page should be disabled.

  4. In addition to the point number 6, If there is null entry done in the payment amount field and if the user clicks outside the box, then the payment amount field will be filled with the value in the Amount remaining field.

Workflow Admin

  1. Once the order is being placed by the customer using the payment method as Invoice Me or Purchase Order, the Orders will be seen on the Order List page in the admin Application.

    1. And the other information as seen in the order list page of the admin application when orders with payment methods Invoice Me and Purchase Orders are placed 

  2. When the Customer makes the payment for the invoice for order against Payment Method Invoice Me and Purchase Order, the status/information for different columns for that order within the admin application will not be updated and will remain the same as they were at the time of placing an order (No matter if the customer is making a partial payment through ACH or complete payment through ACH and Credit Card)

  3. As mentioned in point number 3 of the changes in the admin section of the document, a new section ‘Payment History’ is added in the Manage Order screen within the admin application.


  4. This section within the Manage Order Screen will have same set of columns that will be there in the ‘Payments’ section on the Order Receipt Page on the Webstore which can be seen below:

    1. Date 

    2. Payment Type

    3. Status (the value here will always read as ‘ Pending’ by default but then the admin will have the ability to change the status from pending to received for every payment made against the invoice order. This status will be managed manually by the admin and no automatic changes will be made) 

    4. Amount

    5. Amount Remaining (This will showcase the total amount for the order and will change based upon the payments made by the customers. For Example: Consider that when the order was placed the total amount was $1000. While making the payment for the invoice, if the customer chooses to make partial payment through ACH for say $300. So the amount in the Amount Remaining column will be $1000 - $300 = $700 and this amount will be seen on the Amount Due field on the Make Payment Screen. This Amount Remaining column will get updated upon every payment made by the customer against the invoice till it is ‘0’)

  5. Thus, the only columns (Except the Status) that will update in the admin application for such orders accepting the invoice payments is the columns within this new ‘Payments’ section on the Manage Order Screen

Limitations

  1. This implementation is done in a way showcasing that the Znode has the capability to support Invoice payments through 3rd Party ERP integrations but then the customers/launch teams will have to make the customizations to the same in accordance to their needs.

  2. For the Offline payment methods, only supported payment methods are ACH and CC, if any other payment method is added into this, then these payment methods will be seen in the admin application but then will be hidden on the Webstore

  3. Making payments for the invoice orders will not be applicable from the admin application

  4. The offline payment methods can be used by the customers while making payments for the invoices irrespective of the payment methods within the User profile they are assigned to

  5. Returns are not applicable throughout the invoice payments for this implementation.


Credit card - Cybersource

Adding/Managing a new payment method

  1. .Adding a payment method from Admin >> Payment Methods >> Add New

    1. General Settings

      1. All the standard fields available in this section should be available for all the payment methods and should work in the same way irrespective of the added payment method

    2. Merchant Gateway Settings

      1. When the CyberSource option is selected for the Select A Gateway field

        1. This section should display only those fields which are required to connect the CyberSource merchant account with the Znode application along with the generic fields which are available for all the payment methods.

        2. Remove Accepted Cards field only for CyberSource gateway.

        3. General Info: Znode has no control over the elements displayed in the iframe therefore while creating/managing an iframe-based payment method, irrespective of the value selected for the Accepted Cards field, the acceptable options would load considering the gateway’s merchant account settings.

      2. The generic fields should have the same behavior as available for other payment methods.

    3. Admin users should be able to submit the required information to add a CyberSource payment method in Znode as per the existing behavior.

  2. Managing CyberSource payment method from Admin >> Payment Methods >> Edit

    1. Admin users should be able to update all the necessary information for the CyberSource payment method as per the existing behavior.

  3. Using CyberSource in admin application and web store

    1. After the CyberSource payment method is associated with Store(s) or User Profile(s), it should be available for making payments while creating an Order(normal order or Pending Order or Pending Payments order) from admin and web store, while managing an Order, and while converting a Quote to an Order as per the existing behavior.

    2. The workflow considered to display/hide payment methods for specific users for different store versus user profile scenarios for other payment methods should also be considered for the CyberSource payment method as per the existing behavior.

Payments using CyberSource

  1. Adding a new card for making payments

    1. After selecting the CyberSource payment option, if no card is saved for the user account, then an iframed section to add the card details should appear along with Save this credit card for future use field outside the iframe.
      Note: Save this credit card for future use field should be displayed only for Orders which are placed or are being placed for registered users and for Quotes.

    2. The iframe should load the CyberSource payment section which can be used by admin users or customers (shoppers) to add card details that can be used to make payments while placing/managing an Order or while converting a Quote to an Order from the admin application or web store.

    3. When card details are added to the CyberSource iframe, a token should be generated. If a user selects the Save this credit card for future use field, the last 4 digits of the card along with the token (or Account/Profile ID whatever is provided by the gateway) should be saved in Znode so that the card can be used for making future payments.


  1. Selecting a saved card for making payments

    1. After selecting the CyberSource payment option, if at least one card is saved for the user account, then a section to select a saved card and another section to add the payment details should appear.

    2. Admin users or customers (shoppers) should be able to select a saved card to make payments while placing/managing an Order or while converting a Quote to an Order from the admin application or web store.

    3. The saved last 4 digits of the card and the generated token (or Account/Profile ID whatever is provided by the gateway) should be used to make payments via CyberSource.
      Note: When a section to add new card details is selected, the application should work in the same way as described in point 1.

  2. scenarios of payments from admin application and web store

    1. The workflow considered for other payment methods for scenarios when card details are correct/incorrect, merchant details added for the payment method are correct/incorrect, a voucher(s) is applied to an Order, “Order Total - Voucher Amount” increases due to any changes, card details are saved/not saved for future use, etc should be considered for the CyberSource payment method as well.

  3. When an order is placed from Admin following will be the sequence of the tabs available.

    1. Customer

    2. Cart & Shipping

    3. Review

    4. Payment and Place Order

  4. Review Tab

    1. Customer and Cart & Shipping Details will be displayed in the Review tab

    2. The payment details/section will not be available in the Review tab

    3. Review tab will only have the details visible from Customer and Cart & Shipping tabs

  5. Payment and Place Order Tab

    1. The payment and the order will be placed in the “payment and Place order” tab

    2. Pay button will be visible outside the iframe and once the user clicks on the “Pay” button then the payment will be done and the order will be placed

  6. The above change will be applicable to all the payment methods used for placing a new order and managing an existing order (i.e when the shipping or other details are changed and then for extra payment Authorize.net is used)from Admin screens.

Refund with cybersource

  1. Refunds should be initiated back to the used card via cybersource when changes are made to Order (which uses the Payflow Pro payment method) which reduces “Order Total - Voucher Amount” and when a refund is processed for a Return whose “Return Total - Voucher Amount” is greater than $0 (currency may change)
    Note - Before 9.7 Order Total was calculated and displayed after deducting the Voucher Amount and from 9.7 Order Total and Voucher Amount are displayed separately. Therefore depending on the version, in which this gateway is being implemented in, the value of “Order Total - Voucher Amount” should be considered accordingly.

  2. Scenarios of refunds from admin application and web store

    1. The workflow considered for other payment methods for scenarios when a voucher(s) is applied to an Order/Return, “Order Total - Voucher Amount” reduces due to any changes, the refund is processed for a Return whose “Return Total - Voucher Amount” is greater than $0 (currency may change), Order is not captured when a user tries to process the refund, etc should be considered for the Payflow Pro payment method as well.
      Note: Before 9.7 Order Total was calculated and displayed after deducting the Voucher Amount and from 9.7 Order Total and Voucher Amount are displayed separately. Therefore depending on the version, which this gateway is being implemented in, the value of “Order Total - Voucher Amount” should be considered accordingly.

Credit card - PayFlow

Adding/Managing a new payment method

  1. Adding a payment method from Admin >> Payment Methods >> Add New

    1. General Settings

      1. All the standard fields available in this section should be available for all the payment methods and should work in the same way irrespective of the added payment method 

    2. Merchant Gateway Settings

      1. When the Payflow Pro option is selected for the Select A Gateway field

        1. This section should display only those fields which are required to connect the Payflow Pro merchant account with the Znode application along with the generic fields which are available for all the payment methods

        2. Remove the Accepted Cards field only for the Payflow Pro gateway.

        3. General Info: Znode has no control over the elements displayed in the iframe therefore while creating/managing an iframe-based payment method, irrespective of the value selected for the Accepted Cards field, the acceptable options would load considering the gateway’s merchant account settings.

      2. The generic fields should have the same behavior as those available for other payment methods.

    3. Admin users should be able to submit the required information to add a Payflow Pro payment method in Znode as per the existing behavior.

  2. Managing Payflow Pro payment method from Admin >> Payment Methods >> Edit

    1. Admin users should be able to update all the necessary information for the Payflow Pro payment method as per the existing behavior.

  3. Using Payflow Pro in admin application and web store

    1. After the Payflow Pro payment method is associated with Store(s) or User Profile(s), it should be available for making payments while creating an Order (normal order or Pending Order or Pending Payments order) from admin and web store, while managing an Order, and while converting a Quote to an Order as per the existing behavior.

    2. The workflow considered to display/hide payment methods for specific users for different stores versus user profile scenarios for other payment methods should also be considered for the Payflow Pro payment method as per the existing behavior.

Payments using Payflow Pro

  1. Adding a new card for making payments

    1. After selecting the Payflow Pro payment option, if no card is saved for the user account, then an iframed section to add the card details should appear along with Save this credit card for future use field outside the iframe.

Note: Save this credit card for future use field should be displayed only for Orders which are placed or are being placed for registered users and for Quotes.

  1. The iframe should load the Payflow Pro payment section which can be used by admin users or customers (shoppers) to add card details that can be used to make payments while placing/managing an Order or while converting a Quote to an Order from the admin application or web store.

  2. When card details are added into the Payflow Pro iframe, a token should be generated. If a user selects the Save this credit card for future use field, the last 4 digits of the card along with the token (or Account/Profile ID whatever is provided by the gateway) should be saved in Znode so that the card can be used for making future payments.


  1. Selecting a saved card for making payments

    1. After selecting the Payflow Pro payment option, if at least one card is saved for the user account, then a section to select a saved card and another section to add the payment details should appear.

    2. Admin users or customers (shoppers) should be able to select a saved card to make payments while placing/managing an Order or while converting a Quote to an Order from the admin application or web store.

    3. The saved last 4 digits of the card and the generated token (or Account/Profile ID whatever is provided by the gateway) should be used to make payments via Payflow Pro.

Note: When a section to add new card details is selected, the application should work in the same way as described in point 1


  1. Scenarios of payments from admin application and web store
    The workflow considered for other payment methods for scenarios when card details are correct/incorrect, merchant details added for the payment method are correct/incorrect, a voucher(s) is applied to an Order, “Order Total - Voucher Amount” increases due to any changes, card details are saved/not saved for future use, etc should be considered for the Payflow Pro payment method as well.

Refund using Payflow Pro

  1. Refunds should be initiated back to the used card via Payflow Pro when changes are made to Order (which uses the Payflow Pro payment method) which reduces “Order Total - Voucher Amount” and when a refund is processed for a Return whose “Return Total - Voucher Amount” is greater than $0 (currency may change)
    Note: Before version 9.7 Order Total was calculated and displayed after deducting the Voucher Amount and from 9.7 Order Total and Voucher Amount are displayed separately. Therefore depending on the version, in which this gateway is being implemented in, the value of “Order Total - Voucher Amount” should be considered accordingly.

  2. Scenarios of refunds from admin application and web store
    The workflow considered for other payment methods for scenarios when a voucher(s) is applied to an Order/Return, “Order Total - Voucher Amount” reduces due to any changes, the refund is processed for a Return whose “Return Total - Voucher Amount” is greater than $0 (currency may change), Order is not captured when a user tries to process the refund, etc should be considered for the Payflow Pro payment method as well.
    Note: Before version 9.7 Order Total was calculated and displayed after deducting the Voucher Amount and from 9.7 Order Total and Voucher Amount are displayed separately. Therefore depending on the version, which this gateway is being implemented in, the value of “Order Total - Voucher Amount” should be considered accordingly.


Amazon Pay

Adding a payment method from Admin >> Payment Methods >> Add New

  1. General Settings

    1. Add a new option Amazon Pay Payment under Select a Payment      Type field

    2. All the other standard fields available in this section should be  available for all the payment methods and should work in the same way irrespective of the added payment method.

  2. Merchant Gateway Settings

    1. Select A Gateway field options will be hidden when we select a Payment Type as Amazon Pay.

    2. When the Amazon Pay option is selected for the Select A Gateway field, this section should display only those generic fields which are required to connect Amazon Pay merchant account with Znode application which are:

    3. Select Gateway Mode: Test Mode and Live Mode

      1. Merchant Id 

      2. Access Key

      3. Client Id

  3. The generic fields should have the same behavior as available for other payment methods.

    1. Admin users should be able to submit the required information to add an Amazon Pay payment method in Znode.

  4. Managing Amazon Pay payment method from Admin >> Payment Methods >>Edit

    1. Admin users should be able to update all the necessary information for the Amazon Pay payment method except for the following:

      1. Select A Payment Type

      2. Payment Code

  5. Using Amazon Pay payment in admin application and web store

    1. After the Amazon Pay payment method is associated with Store(s) or User Profile(s), it should be available for making payments while creating an Order from a webstore, while converting a Quote to an Order.

    2. The workflow considered to display/hide payment methods for specific users for different store versus user profile scenarios for other payment methods should also be considered for the  Amazon Pay payment method.

Payments using amazon pay

  1. Adding a new card for making payments

    1. After selecting the  Amazon Pay payment option,  the button will generate “Amazon Pay” which will redirect to the Amazon pay portal for transactions and placing orders.

    2. After clicking on the above button The amazon pay portal will be loaded to login into amazon pay with amazon Email and password or to create new amazon account for payment.

    3. After the login page will be load where all the information related to order will be displayed.

    4. Once payment is done, entry will be available in the amazon sandbox account of the seller.

    5. No save card / save for future user option is available for amazon pay.

  2. Scenarios of payments from web store

    1. The workflow considered for other payment methods for scenarios when card details are correct/incorrect, merchant details added for the payment method are correct/incorrect, a voucher(s) is applied to an Order, “Order Total - Voucher Amount” increases due to any changes, card details are saved/not saved for future use, etc should be considered for the Amazon pay payment method as well.

    2. An AmazonPay provider is created in Payment Application having all the functionalities like refund, validate card, void, capture, and so on.

Allow Authorize payment Only for card connect

While creating payment if we select ‘Credit Card Authorization’ , then order will be ‘Pre-Authorize Transactions Without Capturing’ (Payment status will be authorized).  Admin have to manage the order and change its payment status to capture for successful Transactions .

Allows Authorize and Capture

While creating payment if we do not check ‘Credit Card Authorization’ (Payment status will be captured), then the order will be  placed with successful Transactions (authorize + capture).

Allow refund from return

  1. Refunds should be initiated back to the used card via Amazon Pay when changes are made to Order which reduces “Order Total - Voucher Amount” and when a refund is processed for a Return whose “Return Total - Voucher Amount” is greater than $0 (currency may change)

Note: Before version 9.7 Order Total was calculated and displayed after deducting the Voucher Amount and from 9.7 Order Total and Voucher Amount are displayed separately. Therefore, depending on the version, this gateway is being implemented in, the value of “Order Total - Voucher Amount” should be considered accordingly.

  1. Scenarios of refunds from admin application and web store

    1. The workflow considered for other payment methods for scenarios when a voucher(s) is applied to an Order/Return, “Order Total - Voucher Amount” reduces due to any changes, the refund is processed for a Return whose “Return Total - Voucher Amount” is greater than $0 (currency may change), Order is not captured when a user tries to process the refund, etc should be considered for the Amazon pay payment method as well. Note: Before 9.7 Order Total was calculated and displayed after deducting the Voucher Amount and from 9.7 Order Total and Voucher Amount are displayed separately. Therefore, depending on the version, this gateway is being implemented in, the value of “Order Total - Voucher Amount” should be considered accordingly.


Paypal payment

On the Admin >> Payment Methods >> Add New

Under the General Settings when Paypal Express is selected from the Select a Payment Type dropdown:

  1. Under the Merchant gateway settings:

    1. Apart from the existing fields viz Select Gateway Mode and API Signature (PayPal Only) there will be two more additional fields that will be added:

      1. Paypal ClientId

      2. Paypal ClientSecret
        Note 1 - Both the fields will have text fields associated with them
        Note 2 - Merchant Login, Merchant Account Password which were there previously are removed

      3. Two Checkboxes Viz. Credit Card Authorization and Display Capture in OMS will also be included which will function as per their existing behavior

      4. Rename ‘Credit Card Authorization’ to ‘Payment Authorization

Managing a new payment method

  1. Managing Paypal Express method from Admin >> Payment Methods >> Edit

    1. Admin users should be able to update all the necessary information for the Paypal Express payment method except for the following:

      1. Select A Payment Type

      2. Payment Code

      3. Select A Gateway

  2. Using Paypal Express payment in web store

    1. After the Paypal Express payment method is associated with Store(s) or User Profile(s), it should be available for making payments while creating an Order from a web store, while managing an Order, and while converting a Quote to an Order from the admin

    2. The workflow considered to display/hide payment methods for specific users for different store versus user profile scenarios for other payment methods should also be considered for the Card Paypal Express payment method.

Payments using Paypal Express

  1. Upon choosing the paypal express payment option on the check out page, the User will be redirected to the Paypal site and transaction would be carried out through the same

  2. Scenarios of payments from web store

    1. The workflow to check bank details are correct/incorrect, merchant details added for the payment method are correct/incorrect, a voucher(s) is applied to an Order, “Order Total - Voucher Amount” increases due to any changes, etc should be considered for the Paypal Express payment method

Cancellation for payments made through PayPal Express

  1. On the manage order screen, an order can be canceled in two ways:

    1. By changing the order status to canceled and

    2. By clicking on the ‘Cancel Order’ button

  2. In both cases, the refund for the complete order will be initiated through the manage order screen but only for the orders wherein the payment status is ‘Captured’

  3. For the payment status ‘Authorized’ no refund will be processed through the manage order screen and the payment will be ‘VOIDED’
    Note1: Refund process will work as per how it works for all the other payment methods.
    Note 2: In case of returns, the refunds will be made as per how it works for other payment methods and its process

PayPal Limitations

  1. While placing the order through Znode using Paypal Express, on the Paypal Sandbox, the order amount was shown with complete bifurcations which included the shipping value, Taxes, Discounts and the order total. 

  2. This may lead to penny issues, the reason being for every value of  shipping, Taxes, Discount, system will send to Paypal, Paypal API will round off the amount to 2 precisions (As Paypal just supports precisions only upto 2 decimal points) but Znode admin has the capability to specify the precisions/round off upto 6. Thus, it may lead to penny issue

  3. Thus, to overcome the same, similar to what Znode does for other payment methods, only the order total value will be sent to Paypal without any bifurcated values.

Important Point:

Paypal Express implementation is only done for the payments through the webstore, no implementation has been done to make payment through Paypal express through the admin application


COD

No authorize and capture payment status for COD is required. Payment status submitted as ‘Pending’ and it can be changed as ‘received’ from admin. Refund for COD orders are not considered in Return.


Purchase Order

Adding/Managing a new payment method

  1. Adding a payment method from Admin >> Payment Methods >> Add New

    1. General Settings

      1. All the standard fields available in this section should be available for all the payment methods and should work in the same way irrespective of the added payment method

      2. Admin users should be able to submit the required information to add a Purchase Order payment method in Znode.

  2. Managing Card Connect payment method from Admin >> Payment Methods >> Edit

    1. Admin users should be able to update all the necessary information for the Purchase Order payment method except for the following:

      1. Select A Payment Type

      2. Payment Code

  3. Using purchase order in admin application and web store

    1. After the purchase order payment method is associated with Store(s) or User Profile(s), it should be available for making payments while creating an Order from admin and web store, while managing an Order, and while converting a Quote to an Order.

    2. The workflow considered to display/hide payment methods for specific users for different store versus user profile scenarios for other payment methods should also be considered for the Card Connect payment method.

Payment using a Purchase order

After selecting the Purchase order payment option, one test box will generate a Purchase order account number.

Payment status will be submitted as pending for Purchase order payment.


Note: Remaining payment flow of the purchase order is similar to invoice me.

Allow refund from return

  1. Refunds should be initiated back to the used card via Card Connect when changes are made to Order (which uses the Card Connect payment method) which reduces “Order Total - Voucher Amount” and when a refund is processed for a Return whose “Return Total - Voucher Amount” is greater than $0 (currency may change)
    Note: Before version 9.7 Order Total was calculated and displayed after deducting the Voucher Amount and from version 9.7 Order Total and Voucher Amount are displayed separately. Therefore, depending on the version, this gateway is being implemented in, the value of “Order Total - Voucher Amount” is considered accordingly.

  2. Scenarios of refunds from admin application and web store -
    The workflow considered for other payment methods for scenarios when a voucher(s) is applied to an Order/Return, “Order Total - Voucher Amount” reduces due to any changes, the refund is processed for a Return whose “Return Total - Voucher Amount” is greater than $0 (currency may change), Order is not captured when a user tries to process the refund, etc are to be considered for the Card Connect payment method as well. Note: Before version 9.7 Order Total was calculated and displayed after deducting the Voucher Amount and from version 9.7 Order Total and Voucher Amount are displayed separately. Therefore, depending on the version, this gateway is being implemented in, the value of “Order Total - Voucher Amount” is considered accordingly.




Did you find it helpful? Yes No

Send feedback
Sorry we couldn't be helpful. Help us improve this article with your feedback.