Mobile Payment Solutions

Getting Started

General Integration Workflow:


1. To decide together with the integration team of the NomuPay Mobile Payment integration model for your organization's workflow.

2. Completion of integration by your organization in the decision-making model NomuPay.

3. Completed integration model of mobile payment tests and controls in parallel by your company and NomuPay.

4. Wait for operator approval processes for your company to authorize transactions with your current prices

5. Your company has the authority to make active payments after the approvals.

NomuPay offers a variety of payment methods based on system requirements and transaction volumes for your organization's needs.

These payment methods are;

NOMUPAY Static Common Payment
NomuPay Dynamic Common Payment Page
Merchant Payment Page.

sort in three different ways.

NOMUPAY Static Common Payment Page Integration

Scenario Flow Chart And Usability:

It is an appropriate solution for companies that have few and static number of products, product prices do not change frequently, do not want to do detailed system integration and do sales through a website.
Credit card payment is also possible in addition to mobile payment.

In this scenario, a product is defined by the authority of the company in the NomuPay panel Product Scenario and the static link presented for the product in the panel, is added to the sales page of the product in the website to be sold. This link directs the customer to the NomuPay common payment page for payment and redirects to the site at the end of the process.

For each new product, a new product must be created by authority of the merchant and these prices must be updated as the prices of the products change. These creation and update operations require approval.


For NomuPay Static Common Payment Page Integrations , you can follow the steps below;

  1. At https://www.nomupay.com.tr/management/Login.aspx the merchant logs in with the username and password transmitted by NomuPay via e-mail.
  2. Click on Products link in the information section.
  3. Click the Add New link on the left.
  4. If you want to add products, please follow the steps below in order.Product Scenario
  5. The created product will be approved by NomuPay (by sending a request to tr.bd@nomupay.com).
  6. Click on the Products link on the panel, click on the product detail icon of the related product.
  7. In the page that is opened, the Sales Address link in the Web Sales Channel box is used for sales in the merchant's website.
    • The sample sales address is as follows:
    • A unique ID can be added for each transaction according as the preference of the merchant. For this, the value must be added end of the the address with the parameter mpay: You will be able to query this mpay value or to match your transaction number with the collection number.
      After the customer successfully completes the payment, the customer will be forwarded back to the adrese which is described by the Successful URL at the following table. In this URL the following parameters are added by NomuPay Payments:
      pid Process Number(Old Format)
      mpy The value that can be used for transaction tracking defined by the member business and submitted during the transaction. (NO “mpay” parameter!)
      sid Subscription number (this value will be blank for non-subscription operations) (Old Format)
      order Order Number (New Format)
      subscriber Subscriber Number(New Format)
    • The example result URL is: The description of the fields required when completing the product information is as follows:
      SMS Company Name It is the company name to be seen by the customer. Note: Careful selection is required as this name will appear on the common payment page and on the confirmation SMS.
      Product name It is the product name to be seen by the customer. (Example: Wordpress Theme Sales, Example.com 1 Month Subscription) Note: Careful selection is required as this name will appear on the common payment page.
      Product Category The services / products sold by NomuPay are divided into categories. It is important to choose the right category, because the commission rate of each category is different. If the wrong category is selected and the transaction is made, penalties are applied according to the contract. You can visit our website for current rates.
      Sales Type It is divided into two branhes which is Single Product Sales and Subscription. When Single Product Sales is selected, the system will be charged the designated fee only once. When a subscription is selected, the same amount on a monthly or weekly will be charged on a regular without approval again.
      Description It is information about the content of the product. We remind you that this is very important for customer satisfaction.
      Product Price The price of the product / service you will sell with NomuPay. First, the Lira part and then penny part is written.
      Customer Service E-Posta This is the mailing address of the unit that will provide support for customers and help with payments and orders.
      Web Address The address of the website where you will publish the product. After adding the product, the website will be checked by NomuPay.
      Success URL The customer will be directed to this Internet address when payment is successfully completed. (Example: http://www.example.com/paymentsuccessful.aspx)
      Failed URL The customer will be directed to this Internet address when payment is unsuccessful. (Example: http://www.example.com/paymentunsuccessful.aspx)
  8. One of the methods in the Transaction Result Service section must be used to transfer the payment result to the member business.
  9. If you are using Subscription Product Scenario, a web service development is required as described in the Subscription Notification Service heading.

NOMUPAY Dynamic Common Payment Page Integration

Scenario Flow Chart And Usability:

The NOMUPAY Dynamic Common Payment Page, which a web servis solution and performs payment through the NomuPay common payment page, is a NomuPay solution. It is an appropriate solution for companies that have a large number of products or services with variable prices and do sales through a website. In addition to mobile payment, it is also possible to pay by credit card and TTNET Payment.

In this model, the product and price information of the merchant is sent to the webservice provided by NomuPay. The NomuPay web service, uses the nformation from the merchant website and generates a different link for each process and returns this link as a response to the merchant. The merchant website directs the customer to this link. The customer enters the phone or credit card number on the NomuPay common payment page on this link and is redirected to the website.

Authorization request is sent to integration@nomupay.com.tr for processing with NomuPay Dynamic Common Payment Page in NomuPay system.


Follow the steps below in order NomuPay Dynamic Common Payment Page Integration complete your transactions.


1. Providing our request with Service Input Parameters.

Service Input parameters

  • Input Parameters which send in service
    Parameter Name Data Type Description
    Token Token Class

    Token Informations. The following internal table describes the internal parameters.

    Input Input Class

    Input Informations. The following internal table describes the internal parameters.

  • Token Inforamations
    Parameter Name Data Type Description
    UserCode String

    Merchant value will be shared by NomuPay

    Pin String

    Pin value will be shared by NomuPay

  • Input Informations
    Parameter Name Data Type Description
    MPAY String

    A value defined by the merchant. Use is optional. Values can be ID or username in the merchant system.

    Content String

    Order detail/definition

    SendOrderResult bool

    Request transaction result information by transaction result service
    "True" send information
    "False" do not send indormation

    PaymentTypeId Int

    Payment Method:

    • ‘1’ One Shot
    • ‘2’ Monthly subscription (charged automatically every month)
    • ‘3’ Weekly subscription (charged automatically every week)
    • ‘4’ 2 Week subscription
    • ‘5’ 3 Month subscription
    • ‘6’ 6 Month subscription
    • ‘7’ Month trial (first month is not charged)
    • ‘8’ Month trial (first week is not charged)
    • ‘9’ 2 Month trial (no charge for the first 2 weeks)
    • ‘10’ 3 Month trial
    • ‘11’ 6 Month trial
    • ‘13’ 30 days
    • ‘14’ Daily subscription
    • ‘18’ Yearly subscription

    ReceivedSMSObjectId Guid

    Should be in ‘00000000-0000-0000-0000-000000000000’ format

    ProductList List

    Shows the List that contains the MSaleProduct elements to be sent in the list type. There must be a single MSaleProduct element in this List. The following internal table describes the internal parameters.

    SendNotificationSMS bool

    Information SMS Request to be sent to the user as a result of the payment

    • "True" Send Information Sms
    • "False" Do not Send Information Sms

    OnSuccessfulSMS String

    If the SendNotificationSMS parameter is set to "True", the content of the SMS information to be sent to the user in case the payment is successful. (Turkish characters should not be used).

    OnErrorSMS String

    If the SendNotificationSMS parameter is set to "True", the content of the SMS information to be sent to the user in case the payment is unsuccessful. (Turkish characters should not be used).

    RequestGsmOperator Int
    • Must be '0' on mobile and credit card payments.
    • Must be '20' on TTNET payments.
    RequestGsmType Int

    Should always be sent '0'.

    Url String

    Specifies website on which the operation is performed.

    SuccessfulPageUrl String

    If the transaction is successful, it specifies the page that the customer will be redirected to.

    ErrorPageUrl String

    If the transaction is unsuccessful, it specifies the page that the customer will be redirected to.

    Country String

    This section should be sent empty.

    Currency String

    This section should be sent empty.

    Extra String

    This section should be sent empty.

    TurkcellServiceId String

    During the integration run, '0' is sent until the operator approval is received.
    It is a value that must be used in all mobile transactions, shared by NomuPay to the merchant after the integration is completed and approved by the operators.

  • MSaleProduct Informations
    Parameter Name Data Type Description
    ProductId Int

    Should always be sent '0'.

    ProductCategory Int

    Product/Service Category about Order:

    • '1' Physical Product
    • '2' Game
    • '3' Digital Content
    • '4' Service
    • '5' Social Network / Friendship
    • '6' Dues / Automat
    • '7' Bet
    • '8' Insurance
    • '10' Public - Ticket - Fastfood
    • '11' Pocket Insurance
    • '12' Box Game
    • '14' Mobile Application / Mobile Market
    • '15' Education
    • '16' Donation (only Turkcell subscriptions can make donation payments)
    • '19' Health
    • '20' White Label Adult

    ProductDescription String

    Product Description

    Price Double

    Amount be paid.

    Unit Int

    Should always be sent '0'.

Service Output Parameters

  • Service Output Parameters
    Parameter Name Data Type Description
    RedirectUrl String

    The end user will be redirected this URL to enter credit card information The address is NomuPay Common payment page which the customer is directed.

    StatusCode Int

    A value of '0' shows that the NomuPay Dynamic Common Payment Page has received sales link generation information. The process is started.
    A value of '1' shows that the NomuPay Dynamic Common Payment Page has not received sales link generation information. The process is not started.

    ErrorCode String

    NomuPay Dynamic Common Payment Page generation sales link transmission error code.

    ErrorMessage String

    NomuPay Dynamic Common Payment Page generation sales link transmission error description.


Should bu used one of the methods in the Transaction Result Service part for sending the payment result to merchant. Successful and unsuccessful result pages are created to give information to users. In the event of a system failure, it is necessary to use transactional services in order to avoid situations where the end user does not have access to the successful or failed page. To transfer the payment result to member merchant Process Result Service one of the methods in the chapter should be used.

3. If you want to use your product as a subscription, a web service development is required as described in the Subscriber Deactive Information Service heading.


Merchant Payment Page Integration

Scenario Flow Chart And Usability:

It is an appropriate solution for companies that have a large number of products or services with variable prices, work on web service based, sells frequently through a website (in some cases sales can also be started by SMS), not use NomuPay common payment page in the payment process, and customer does not leave the merchant's website during process.


In this model, the merchant receives the phone number of customer from own site. The process is initiated by transmitting phone number, price and category data to the NomuPay web service. The operation is asynchronous, so the result is queried by a different web service method.


Authorization request is sent to integration@nomupay.com.tr for processing with Merchant Payment Page in NomuPay system.


Follow the steps below in order to complete your NomuPay Member Merchant Payments Page Integration process.


1. Providing our request with Service Input Parameters.

Service Input Parameters

  • Input parameters in the service
    Parameter Name Description
    Token

    Token Informations. The following internal table describes the internal parameters.

    Input

    Input Informations. The following internal table describes the internal parameters.

  • Token Information
    Parameter Name Date Type Description
    UserCode String

    Merchant value will be shared by NomuPay

    Pin String

    Pin value will be shared by NomuPay

  • Input Informations
    Parameter Name Date Type Description
    MPAY String

    A value defined by the merchant. Use is optional. Values can be ID or username in the merchant system.

    Gsm String

    Customer phone number. Should be in 5XXXXXXXXX format.

    Content String

    Order detail/description

    SendOrderResult bool

    Request transaction result information by transaction result service
    "True" send information
    "False" do not send indormation

    PaymentTypeId Int

    Payment Type:

    • ‘1’ One Shot
    • ‘2’ Monthly subscription (charged automatically every month)
    • ‘3’ Weekly subscription (charged automatically every week)
    • ‘4’ 2 Week subscription
    • ‘5’ 3 Month subscription
    • ‘6’ 6 Month subscription
    • ‘7’ Month trial (first month is not charged)
    • ‘8’ Month trial (first week is not charged)
    • ‘9’ 2 Month trial (no charge for the first 2 weeks)
    • ‘10’ 3 Month trial
    • ‘11’ 6 Month trial
    • ‘13’ 30 days
    • ‘14’ Daily subscription
    • ‘18’ Yearly subscription

    Url String

    The website where the payment was made.

    ProductList List

    Shows the List that contains the MSaleProduct elements to be sent in the list type. There must be a single MSaleProduct element in this List. The following internal table describes the internal parameters.

    ReceivedSMSObjectId Guid

    Should be in ‘00000000-0000-0000-0000-000000000000’ format.

    SendNotificationSMS bool

    Information SMS Request to be sent to the user as a result of the payment

    • "True" Send Information Sms
    • "False" Do not Send Information Sms

    OnSuccessfulSMS String OnSuccessfulSMS

    If the SendNotificationSMS parameter is set to "True", the content of the SMS information to be sent to the user in case the payment is successful. (Turkish characters should not be used).

    OnErrorSMS String

    If the SendNotificationSMS parameter is set to "True", the content of the SMS information to be sent to the user in case the payment is unsuccessful. (Turkish characters should not be used).

    RequestGsmOperator Int

    Should always be sent as '0'.

    RequestGsmType Int

    Should always be sent as '0'.

    TurkcellServiceId String

    During the integration run, '0' is sent until the operator approval is received.
    It is a value that must be used in all mobile transactions, shared by NomuPay to the merchant after the integration is completed and approved by the operators.

    CustomerIpAddress String

    IP address information of the end user who has performed the payment transaction (entering the card number on the payment page and clicking the "make payment" button)

  • MSaleProduct Informations
    Parameter Name Data Type Description
    ProductId Int

    Should always be sent as '0'.

    ProductCategory Int

    Product/Service Category about Order:

    • '1' Physical Product
    • '2' Game
    • '3' Digital Content
    • '4' Service
    • '5' Social Network / Friendship
    • '6' Dues / Automat
    • '7' Bet
    • '8' Insurance
    • '10' Public - Ticket - Fastfood
    • '11' Pocket Insurance
    • '12' Box Game
    • '14' Mobile Application / Mobile Market
    • '15' Education
    • '16' Donation (only Turkcell subscriptions can make donation payments)
    • '19' Health
    • '20' White Label Adult

    ProductDescription String

    Product Description

    Price Double

    Amount be paid.

    Unit Int

    Should always be sent '0'.

Service Output Parameters

  • Service Output Parameters
    Parameter Name Data Type Description
    OrderObjectId Guid

    Order Id. Used to query the result of the process.

    Gsm String

    Telephone number which will be charged. (5XXXXXXXXX format)

    GsmOperator Int

    Should always be sent '0'. Look at the next clause for find which operator is being processed.

    GsmType Int

    Should always be sent '0'. Look at the next clause for learn to if the operator line is postpaid or prepaid.

    State Int

    Process Status. This value is not final. Look at the next clause for learn to result.
    Values less than 100 shows that payment continues.
    Values 100 payment is successful.
    A value greater than 100 shows that the payment is unsuccessful.

    OrderChannelId Int

    Should always be sent '104'.

    PaymentCategoryId Int

    Product/Service Category of Order:

    • '1' Physical Product
    • '2' Game
    • '3' Digital Content
    • '4' Service
    • '5' Social Network / Friendship
    • '6' Dues / Automat
    • '7' Bet
    • '8' Insurance
    • '10' Public - Ticket - Fastfood
    • '11' Pocket Insurance
    • '12' Box Game
    • '14' Mobile Application / Mobile Market
    • '15' Education
    • '16' Donation (only Turkcell subscriptions can make donation payments)
    • '19' Health
    • '20' White Label Adult

    LastTransactionDate DateTime

    Date of the payment transaction.

    MPAY String

    Merchant defined value.

    SubscriberId Guid

    This value will be returned empty. If the transaction is a subscription ,the method is used to find the subcription Id in the next clause.

    PIN String

    This value will be returned empty. If the transaction is pin-scenario, the method is used to find the PIN value sent to the user in the next clause.

    MicroPaymentResults List

    These parameters will be blank because the process has not been completed. MMicroPaymentOutput represents the list that contains the elements. The parameters of MMicroPaymentOutput are described in the following internal table.

    StatusCode Int

    Shows the order status code. If it returns '0', it shows that the order has started successfully. It does not mean that the payment is successful.

    ErrorCode String

    Shows the order error code. It is sent by the operator. It is an error code about order payment.

    ErrorMessage String

    Shows the order error description. Description of the error code.

  • MMicroPaymentOutput Informations
    Parameter Name Data Type
    PaymentObjectId Guid
    StatusCode Int
    ErrorCode String
    ErrorMessage String

3. If you want to use your product as a subscription, a web service development is required as described in the Subscriber Deactivate Information Service heading.

SMS-Keyword Integration

Scenario Flow Chart And Usability:

In this scenario, sales can not be done on the a website. A product is created by the merchant in the NomuPay system and a keyword associated with the product is defined. The merchant sends this keyword to the customer via certain information channels (web site, newspaper advertisement, brochure, etc.). The customer starts the process by sending this keyword to 7979 by SMS and sales are completed. A web service development is required by the merchant as described in Transaction Result Services title for sending transaction to the merchants in this scenario. The transaction results will be forwarded to this web service by NomuPay Payment.If you want to use your product as a subscription sales with sms-keyword integration, you need a web service development as described in the Subscriber Deactivate Information Service heading.


You can complete your Sms-Keyword Integration transaction by following the steps below;
  1. https://www.nomupay.com.tr/management/Login.aspx by the user name and password transmitted by the member company via NomuPay via e-mail.
  2. Click on Products link in the information section.
  3. Click the Add New link on the left.
  4. Follow the steps in the Product Scenario section in order for you to add items.
  5. The created product will be approved by NomuPay (by sending a request to tr.bd@nomupay.com).
  6. The keyword is specified with the NomuPay integration authority (integration@nomupay.com.tr), and the integration authority associates this keyword with the product.
  7. Use Transaction Result Service for learning transaction result.
  8. If you are using subscription Product Scenario , a web service development is required as described in the Subscriber Deactivate Information Service heading.

SMS-Keyword Integration (With Pin)

Scenario Flow Chart And Usability:

Pin is a disposable password that will enable a customer to buy a product or service. A pin is sent to the customer from 7979 at the end of the flow in the SMS-Keyword model.

Pin should be unique because it is disposible. Also, a pin used in one process can not be reused in another process..


You can complete your Sms-Keyword Integration (with Pin) process by following the steps below.
  1. https://www.nomupay.com.tr/management/Login.aspx by the user name and password transmitted by the member company via NomuPay via e-mail.
  2. Click on Products link in the information section.
  3. Click the Add New link on the left.
  4. Follow the steps in the Product Scenario section in order for you to add items.
  5. The created product will be approved by NomuPay (by sending a request to tr.bd@nomupay.com).
  6. The keyword is specified with the NomuPay integration authority (integration@nomupay.com.tr), and the integration authority associates this keyword with the product.
  7. The pin list to which the customer will be sent is sent to integration@nomupay.com.tr with the product name.
  8. Use Transaction Result Service for learning transaction result.
  9. If you are using subscription Product Scenario , a web service development is required as described in the Subscriber Deactivate Information Service heading.

SMS-Keyword Redirect Integration

Scenario Flow Chart And Usability:

In this scenario, the product can not be produced by the merchant. The customer initiates the transaction by sending a SMS to 7979 with expression adding at the end of keyword which be defined by the merchant.
Example SMS: “BUY 150”
“BUY” part is the keyword prefix in this example. The "150" part is solved by the system of the merchant to determine how to make a purchase (for example, if the customer buys 150 points).
There is a difference in the systematic flow of this scenario. Firstly the merchant must develop a webservice as describes in the SMS Content Delivery Service title. The message sent by the customer to 7979 is forwarded by NomuPay Payment to the merchant via the SMS Content Delivery Service. The merchant system determines price which weill be charged from the customer by solving the contents of this message. It then provides the payment transaction by using the webservice described at The Merchant Payment Page Integration title.


You can complete your Sms-Keyword Redirect Integration by following the steps below.
  1. A keyword prefix is defined by the mercant with the NomuPay authorities.
  2. A web service is developed as described in the SMS Content Delivery Service title.The message text that customers will send to 7979 with the related keyword prefix will be forwarded to this web service by NomuPay..
  3. Information is sent to integration@nomupay.com.tr to identify the selected keyword.
  4. Transmitted SMS texts are solved by the merchant system and determined the amount to charged from the customer.
  5. Charged amount send the web service as describes in the Merchant Payment Page Integration title.
  6. Use Transaction Result Service for learning transaction result.

Sample Service Request Codes